How to organize a ASP.NET MVC solution (DDD)

Question

Hello everyone.
I am trying to start a new project (asp.net MVC) and I would like to apply some DDD rules I've learned in these last few months.
I don't know how to organize my solution though.
I would like to use Nhibernate but I don't want to use Fluent Nhibernate cause it must be something like an experiment.
I've seen some examples where people keep everything in the same project. Some others tend to create a different project for everything. Do you think I should differentiate the model and the repository or put it in the same project?
If someone has some links to articles etc it would be appreciated.

thanks

Alberto

Answer 1

Jimmy Bogard (author of Automapper) has written an excellent article on how he structures his code, which may assist in helping your decision.

I've worked on projects with tons of separate assemblies and projects that have a small number. My personal preference is to have fewer assemblies as I always find it easier to work with. If you use good coding principles (like SOLID) then it shouldn't matter if you use 2 or 20 assemblies.

Answer 2

It depends how big is your project, but I would go for different projects for the model and the repository. In my opinion, it's not suitable to keep your model's stuff in the model folder of the WEB Mvc project. It gets too crowded there :)

It's is important in DDD not to introduce technology specific elements in your domain logic (like NHibernate you intend to use or any other ORM for example). This is usually with creating the so called anti-corruption layer.

In addition to repository pattern, consider using using specification pattern for filtering data coming from the repository.

Answer 3

MVC2 has the concept of areas which create seperation of concern. I still do not like how it is implemented. I create a seperate project for virtually every controller. That way I can mix and match controllers in new projects i work on. Great example is I have a project called "Security" which handles all login and user management stuff. Another project I have is called Notification which handles all messaging and emails. What I do to pull these together is I create a core project for whatever project I am working on, and then I import in the dll's from the other project and all I have to ensure is I have the views and javascript in place and it will work.

Answer 4

I personally think dividing each layer into a separate project is a better idea. There are certain things that you cannot achieve with having 1 big ASP.NET MVC project that includes all your layers.

For example, assume you have a Product and ProductFactory class. You would like to enforce the creation of a Product object to be done via ProductFactory. To achieve this, you can make the constructor of Product class internal. This way, ProductFactory class can instantiate a Product class because Product and ProductFactory are in the same assembly. However, if you try to instantiate a Product class from another project (i.e. your ASP.NET MVC project), you will receive a compile-time error. This way you can achieve a better encapsulation.

Note that if Product, ProductFactory and your Controller are in the same project, you can still see the Product's constructor in your Controller. So an amateur developer who does not understand the architectural decisions behind your design and can simply ignore the ProductFactory and create a Product object directly.

Plus, having a separate project for each layer makes your maintenance easier because you have to deal with smaller projects, as opposed to 1 big project.