>

Ayende has a nice post on structuring of solutions and projects. This is an interesting topic and there is a lot of interesting suggestions in the comments.  In the post Ayende argues for "2 project solutions", one for the application and one for the tests. I'm not a believer of solutions with huge numbers of project but I would argue for a bit more that 2 projects to enable me to enforce isolation by setting project references and then telling the devs not to add references without consulting the rest of the team. (read: Forbid them to add new references between projects :)

Udi Dahan summarizes this nicely with this comment:

Knowing who depends on what, and, more importantly, who should NOT depend on what is critical in scaling a project in terms of number of developers and size of code base. Being able to just look at the list of referenced projects and see a misplaced dependency is the first thing I look for in code reviews.
"Why do you have a reference to System.Data.SqlClient in your Domain Model?"

If I would setup a new web project today the structure should be something like this:

  • MyApp.Domain : Domain objects
  • MyApp.Services : Domain services
  • MyApp.Infrastructure - Wrappers for external systems
  • MyApp.Web - Content + MVC - classes
  • MyApp.WebServices : Web-Services published be the application
  • MyApp.Tests : Unit tests and Integration tests

This works great for the small to medium size web projects that I'm involved in.