Over a million developers have joined DZone.

How to Split a Monolith Solution (Part 3): Compilation Tiers

DZone's Guide to

How to Split a Monolith Solution (Part 3): Compilation Tiers

In the final part of our series, we take a look at how compilation tiers play a role in splitting up your monoliths.

· Integration Zone
Free Resource

Modernize your application architectures with microservices and APIs with best practices from this free virtual summit series. Brought to you in partnership with CA Technologies.

In my previous article, I used a term "compilation tiers," but I didn't define it. But before the definition, I have to describe all the possibilities of the split. To make it easier, let's assume that we split our big solution into two smaller ones: solution one and solution two. Now we have following possibilities:

Solution Two Depends on Solution One

A picture is worth 1,000 words, so here it is:

The most interesting part of above picture is the green arrow. It represents dependencies, usually called artifacts. The artifacts can be following:

  • Packages like Nuget packages/Maven packages/npm packages/etc.
  • Plain files like simple code files/dll files/protobuf schema/etc.

About the solutions, we can say:

Solution one produces some kind of artifacts that are needed by solution two during or before the build. It is not a run-time dependency. It is a compilation dependency.

Solution One Depends on Solution Two

Second verse, same as the first.

Solution One and Two Don't Have Any Relationship

Again 1,000 words:

How can that happen? I wrote about this in my first article. In most cases, there is a run-time dependency instead of a build dependency. The second option is simpler: The projects just don't relate to each other at all. For example, a database migration tool and mobile app. They just don't have any relation.


We can define a compilation tier as a subset of all projects without artifact dependencies to each other. The only artifact dependency can be to a previous compilation tier.

Making the above simpler: You can compile solutions from one compilation tier in parallel.

Real Life

Finding the first seam is quite easy. The first split is probably easy, too. But a month or two pass away, and you will start to worry whether you did a good job. Are your compilation tiers correct?

To find out you will have to create a checklist:

  1. You don't have circular dependencies between tiers. After you introduce a package manager, it can be easy to create them. All packages already exist in the artifact repository.
  2. You can compile everything from zero. Very similar to the above.
  3. Most changes are in the last tiers. If you do a lot of changes in first tiers, it suggests that every time you do so, you will have to compile everything.
  4. You didn't create too many tiers. I think a number between five and 10 is the maximum. In most projects, it should be below five.

The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.

database ,compilation ,dependency ,migration

Published at DZone with permission of Piotr Stapp, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}