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.
Join the DZone community and get the full member experience.Join For Free
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.
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:
- 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.
- You can compile everything from zero. Very similar to the above.
- 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.
- 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.
Published at DZone with permission of Piotr Stapp, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.