How to split a huge solution into smaller pieces

Question

In my every-day work solution we have 80 projects circa. This solution contains 4 different web-sites, the business logic and the infrastructure assemblies (such as extension methods, various utilities, repository base classes and so on).

The solution works quite good but if we add the test projects to the solution we easily pass over 100 projects which makes working with this solution very tedious.

In my search for a solution, I got really interested by Nuget and I started wondering if it can help us.

The idea would be to split the huge solution into smaller atomic pieces whose output would be a Nuget package to be uploaded to a private Nuget repository.

The web-sites will be referencing the packages other than a class-library bound to that specific web-site.

From the CI point of view:

Each package solution should be atomic.

• It should be able to fetch its references (other NuGet packages, both from the official feed and the private one);
• Build
• Run its tests
• Assemble a package
• Upload the new package to the repository

The product solutions (say the web-sites) should be build after:

• A commit of their code
• An update of the NuGet packages on the private repository

Any suggestion? Or maybe a better way to achieve the split of this huge solution?

Answer 1

Using package management (on Windows: NuGet) is certainly a solid approach here. You get dependency resolution 'for free' and can take advantage of semantic versioning for communicating meaningful information to package consumers merely through the package version number.

However, NuGet is in effect a specific implementation of some more fundamental patterns:

1. Only build code that has changed
2. Decompose systems into small, manageable units
3. Do not build 'frameworks'

From your question, it sounds like you are building more code than necessary, and that your code is less modular than it could be. Using NuGet to modularise your code will help to implement these three patterns (certainly 1 and 2 - you'll need to take additional steps for 3).

Applying these patterns will help @Fede too (for whom - with C and C++ code - NuGet is not applicable). Generally, by making your software more modular (yet avoiding the trap of building a monolithic, all-knowing 'framework', usually called *.Library.dll, or *.Common.dll, etc.) you will achieve better build architecture.

Ultimately, each 'chunk' of code (Project or Solution in Visual Studio terms) should be comprehensible to a single developer; if it's too unwieldy or complicated, split it up. Projects, Solutions, .cs files, etc. are all abstractions for humans, not for machines, so the size and relationship between them should reflect our human abilities and need for understanding. Taking that too far will lead to the need to change multiple packages to complete a single feature: in this case, the separation by definition is to granular, and you'll need to re-group some code together again.

(Disclosure: I am the co-author of Windows Package Management - PackageManagementBook.com)