After 15 years of taking over other .NET developer their solutions, one thing that always flabbergasts me is…
All the reasons why they have created dozens of projects in their solution.
I even, once in a while, come across a 100+ projects in 1 solution in the wild that tries to bring down Visual Studio in its path.
I see even amazingly simple applications, like a console utility, producing multiple libraries for no good reason.
But why?
❌ We want to prevent developers from mixing layers. It provides a separation by concern driven by the compiler.
❌ We don’t mix interfaces with concrete types. This makes reusing the interfaces very easy.
❌ Each namespace needs to have its own project. This is easier to see where code lives.
Projects are for modularization, for package management: it’s a component that you share with the world and/or need to deploy.
Principles I use when to create a new project:
✅ Release Equivalence Principle (REP)
Code that makes sense that you release and version together. What if you would make a NuGet package and versioning it? People that would use it would be dependent on the releases and look closely at the versions to keep track of it.
✅ Common Reuse Principle (CRP)
Code that you reuse most of the time together, should be together. If you reference the library, would that be enough, or are you forced to reference other libraries? If yes, you are probably better off merging them.
✅ Common Closure Principle (CCP)
If a normal change affects a certain code, then that code should probably be together.
Most of the time, you just keep the urge to create a new project for yourself and wait until you feel friction. That friction should be a hint to look if adding a project would solve the situation.
