How to Split a Monolith Solution (Part 2): Find the Seams
When splitting up your monolithic solutions, you need to know where to look. This post guides you through finding the cracks in your solution, which you can use to split it.
Join the DZone community and get the full member experience.Join For Free
In the first part of this series, I wrote about common myths of splitting monolith solutions. In this post, I will try to find "lines" to cut using the Visual Studio and ReSharper. Let's go!
- Big solution.
- Will for change.
I will use .NET solution and tools because I know them the best.
- 67 projects.
- 36 projects on root.
- 2 sub-folders with projects.
- 19 projects with tests.
In the Visual Studio, it looks like below:
To start working, we need to visualize dependencies. And in this part, ReSharper saved my day.
With ReSharper, you can explore project dependencies in your solution using a visual representation of the solution architecture. At any time, you can open the Architecture View (ReSharper | Architecture | Show Project Dependency Diagram) and explore project dependencies without compiling anything.
If you know other tools that can do the above, please let me know in comments.
Anyway. Click on
ReSharper->Architecture->Show Project Dependency Diagram below image showed. (Yellow and green rectangle I added myself using paint):
What did I notice?
- There are three projects without a reference to anything else. One is a yellow group on the left. There are more groups like this, but in the overview, I don't see them clearly.
- My solution folders are marked with black background rectangles. The left-hand side is
- The green rectangle marks a big separated part. There isn't anything with reference to this part.
The good thing is that I have a folder where I can use collapse graphs into smaller groups. Just click:
In my case it looks, like the following:
After the collapse, I noticed more:
1. I have only one arrow down — arrows show dependency between projects.
2. I have more project without a reference.
3. I can easily create compilation tiers. There are seven layers in the above picture.
The most interesting point is number 2. Why do I have unrelated projects? I see following possibilities:
- Tools without direct dependency, like MSBuild tasks, file converter, UI test stuff, DB helpers, etc.
- More complex infrastructure: The above solution is not the only one in the project.
- Something more? Let me know if there is.
As you think about the first two groups, we can easily move on. In my case, it's nine projects from 67. That's ~13% of all projects in the solution. If I exclude tests projects, it is ~18%. So I just make my solution a bit smaller.
After the quite simple above steps I noticed that:
- I have parts that can be easily separated.
- Most my references are one-way. From bottom to up. I can easily create compilation tiers.
- Folders in big solution are good in the overview.
What's coming next?
- Dependency management for compilation tiers.
- Split or remove circular dependencies in grouped projects.
Published at DZone with permission of Piotr Stapp, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.