Managing Loosely Coupled Projects by Mark Seemann
Udi recently posted an article on managing loose coupling in Visual Studio. While I completely agree, this is a topic that deserves more detailed treatment. In particular, I'd like to expand on this statement:
"In fact, each component could theoretically have its own solution"
This is really the crux of the matter, although in practical terms, you'd typically need at least a couple of projects per component. In special cases, a component may truly be a stand-alone component, requiring no other dependencies than what is already in the BCL (in fact, AutoFixture is just such a component), but most components of more complex software have dependencies.
Even when you are programming against interfaces (which you should be), these interfaces will normally be defined in other projects.
A component may even use multiple interfaces, since it may be implementing some, but consuming others, and these interfaces may be defined in different projects. This is particularly the case with Adapters.
Finally, you should have at least one unit test project that targets your component.
In essence, while the exact number of projects you need will vary, it should stay small. In the figure above, we end up with five projects, but there's also quite a few abstractions being pulled in.
As a rule of thumb I'd say that if you can't create an .sln file that contains less than ten projects to work on any component, you should seriously consider your decoupling strategy.
You may choose to work with more than ten projects in a solution, but it should always be possible to create a solution to work with a single component, and it should drag only few dependencies along.