CODEWITHSUNDEEP
c#asp.net-mvcentity-frameworkdomain-driven-designasp.net-mvc-5
Brendan Hill
Brendan Hill

Reputation: 3742

Folder structure in MVC + Domain Driven Design

I'm commencing an MVC5 + DDD + EF6 project and producing a skeleton solution. I have two questions about best practice / convention:

1) The Models folders in the MVC project seem redundant as the models are actually in the Domain. If any Views require a dedicated ViewModel, then I understand a ViewModels folder is appropriate instead.

Is a ViewModels folder in each MVC area appropriate, and are the Models folders in the MVC project ever likely to serve any purpose?

2) In my previous project, we referred to the Domain Models as "Models", however I understand some call them "Entities" due to the terminology in Entity Framework.

My intention in the new project is to create some rich behavior in some Domain Models, they will not merely be dumb DTOs (data transfer objects).

Within the Domain layer, is convention / best practice to call them Models or Entities?

Upvotes: 0

Views: 2840

Answers (2)

Bartłomiej Szypelow
Bartłomiej Szypelow

Reputation: 2121

You can rename the Models folder to ViewModels if you like. Nothing will break.

But I prefer to leave it as is and then call ViewModels the client-side objects only (Knockout or similar stuff).

I prefer having Entities flolder in domain layed.

Upvotes: 1

Eugène
Eugène

Reputation: 676

My opinion is this:

1) If a always create a view-model for a view, even when it feels like a 1 to 1 mapping currently. (you can use something like AutoMapper to help with the repetitive coding tasks here. The reason is that your domain and view look very similar now, but 6 months from now a lot has changed in your domain as you build knowledge of what is required, and your view does not map 1 to 1 to your domain model anymore. Keep a ViewModels Folder in each area, and by the time you need a reusable ViewModel, refactor and move it to a common area.

2) Domain items can be entities / models, it's pretty much different everywhere you go. As long as the team is in agreement as to when an entity is code item or entity is the thing in real life you are trying to represent... it is all fine. As your ubiquitous language develops, things become easier. Definately agree with making the domain as rich as possible, as it helps to handle complexity when the system gets big. Keep the Eric Evans - Domain Driven Design book on your table, and all the best with the new project.

Upvotes: 4

Related Questions