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

Today’s data climate is fast-paced and it’s not slowing down. Here’s why your current integration solution is not enough. Brought to you in partnership with Liaison 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.

Is iPaaS solving the right problems? Not knowing the fundamental difference between iPaaS and iPaaS+ could cost you down the road. Brought to you in partnership with Liaison Technologies.

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 }}