Introduction
When our applications or the system (set of connected applications) grow, we would require separating the code into components and distribute it to the application developers. This post is discussing how to design dependencies. Big dependencies or smaller dependencies
Importance of dependency management system
Though our system is not big, it is good to adopt a dependency management system. Also good to channel the public dependencies too the same repository of packages. Some reasons, not a complete list below
- It helps to have a central repo. Easy to control what versions of dependencies are allowed to use. Otherwise, later it will be difficult to understand what all dependencies are used in our organization.
- It increases code reuse
- Less compile time as all the dependencies don't need to be compiled with the application change. This is arguable as the application compilation requires dependency download time.
- Easy to track usage of code by package download and decommission.
Dependency design
Now coming to the main point. When we split our code how should we split it? Should we create a single package named cross-cutting and include everything there such as logging, caching, etc... or create single responsible packages.
| Criteria | Big package | Smaller single responsible packages | Comments |
| Package selection | Lessor one package to refer to. Consumers just refer it. | There may be packages doing similar things. The difference may be very less and difficulty in choosing | |
| Change management | Consuming developers may require only one class change. But they get full changes. This adds regression testing efforts | Consumer developers need to make sure every package is up to date.
But easy to test package version upgrade |
|
| Package release agility | High chance that it may follow the release of the monolith application where developers of individual classes or components in the package have to wait for green signal from other teams to release package version. | Each package dev team can release at high speed. |
|
| Package support | Only one big team to reach out. Consumer life would be easy. | Based on organization structure the package authoring teams may scatter causing consumers difficulty to get support | |
What industry follows?
The leading dependency management system NPM for Node.JS generally follows the second approach of smaller packages. Every package does one thing and does it well. Often using other packages to achieve something and expose that Facade kind of API.
The .Net Nuget system was not atomic like the NPM. But with .Net Core or Future .Net it is also following the Node.JS path of
separating bigger packages into small atomic.
Answer
My answer is
atomic package model where one package does one thing and does it well.
Below are the rationale
- The industry is going agile. ie shorter release times.
- Microservices would be the main consumers of packages. They are small and why should they carry bigger package foot prints?
If we look at one of my nuget library DotNet.Helpers, that is not following this design. It has different components even from different technologies. That package has created to store my knowledge and reusable code than evolved from large projects.
My prediction is that software industry will converge to one technology and Node.JS or its successor Deno will replace .Net for desktop and web programming. So before I am stopping .Net, I am just storing my knowledge. Its just my prediction similar to I predicted death of Silverlight and WPF.
Things may change as Blazor is emerging and it may (very less chance) get popular and .Net will survive.
