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.