What to focus on when separating a monolithic codebase into separate (NuGet) packages?

Question

I work on a fairly large web application. The main solution containing the web application project has over 100 projects. The average build time of that solution is 2 minutes on a 12 GB quad-core machine with an SSD.

We are looking into ways we can improve our deployment process. I am going to work on a proof-of-concept to move code out of the main source repository into separate repositories, to be built and packaged as NuGet packages. These will be hosted on an internal feed and installed into the main solution from there.

For the proof-of-concept I want to focus on the most important/challenging aspects. I have some experience building stand-alone libraries, and of course the experience of working on this monolithic codebase. I would like to ask you:

What should I focus on for the proof-of-concept?

---

Some areas I think I should experiment with:

• Versioning

• Assembly binding

• Unit testing

• ILMerge to merge dependencies

• Debugging

• Performance

PS. Automating the building and publishing of packages to the NuGet repository is not my responsibility.

• Tom Barron: Does the project have a primary objective? For example, one objective might be to reduce the total build time. You also say you want to "improve our deployment process." What are the specific metrics you want to change? How will you know whether the changes you make are improvements or not?

Answer 1

NuGet is just a package manager. Providing that it is the focus of your question, can you really say that the architecture of your project is already good enough and it's just package management that is missing? Otherwise, perhaps, the question should be reworded to focus on refactoring the monolithic architecture rather than introducing package management?

Saying that, here is what worked for me:

1) slice the solutions across business and concern boundaries: e.g. people, authentication, business modules;

2) apply the micro-services architecture;

3) package the very common helper types and functions: framework package.

4) package the common patterns / cross-cutting concerns: Repository Pattern package, Logging package, Caching package, REST package etc.

5) create a client package for every micro-service to benefit from the strong typing.

• Michiel van Oosterhout: Thanks for your thoughtful answer. We are also working on refactoring to better fit the package model. Some parts seem to fit really well (e.g. caching), others definitely need more work. Thank you for the micro-services tip.