Moving past the monolith, Part 6 – Using package managers to share common code

This is part of a series of posts about Moving Past The Monolith. To start at the beginning, click here.

In my last post, I talked about creating “shared modules” that contain code that is needed across modules. Most applications will have a need to have something like this, and it can be very useful.

There are two ways to consume the shared module. You could include it in with all of your other application code, and other modules can reference it directly. In some cases, this makes sense, but now you have a problem — anytime you change something in the shared modules and it affects the consumers, all of the consumers must be updated to handle the change. If the consumers are deployed independently, you might not want to have to change that much code.

The second way to is distribute the shared module through your package manager (NuGet, rubygems, npm, etc.). The beauty of using the package managers is that package managers can store different versions of a packages, so consumers get to decide when they opt into the changes. This gives you the freedom to change shared code, but not impact consumers that don’t want to accept the changes (e.g. legacy code or things that you don’t want to retest and deploy). All of these package managers allow you to set up your own server to host packages so that you can have your own internal package source that isn’t exposed to the outside world.

This can get a little tricky when the shared module changes involve breaking database schema changes. Things like this would force all consuming modules to get updated, but you probably knew you were getting that when you decided to make the schema changes.

It’s not always that easy

While this approach might seem simple and straight-forward, it actually has some quirks to be aware of. Here are some things to watch out for.

  • Be careful of adding dependencies in your shared module that are exposed to the consumers, because you’re effectively forcing those dependencies on your consumers. A classic example is when someone adds a reference to an IoC container to the shared module, but one of the systems consuming the shared module uses a different IoC container, so things don’t work.
  • Any time your dependencies are exposed to consumers, the shared module and the consumers are forever tied to the same version of that dependency. This means that a dependency version update in the shared module will force all consumers to make the same update, and consumers will not be able to update their versions unless the shared module makes the same update.
  • There is a difference between shared modules that are explicitly created for sharing between modules in the same application and shared modules that are meant to be shared across applications. In the first case, you’re more likely to accept the version coupling that I’ve talked about, but in the latter case, you really don’t want to introduce version coupling between shared modules and many different applications (especially if they are owned by different development teams).

Read the next post in this series, Splitting up your client-side applications.