Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Split a Monolith Solution (Part 1): Common Myths

DZone's Guide to

How to Split a Monolith Solution (Part 1): Common Myths

The microservices mentality seems to be here to stay. We're going on a three-part journey of splitting your monolithic architecture. Step 1: Dispelling some common misconceptions.

· Integration Zone ·
Free Resource

The Future of Enterprise Integration: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.

Do you have a big and heavy solution? Do you want to split it? Are you afraid? I will try to help. Be for we start, though, we should answer a few questions.

Why Should I Split?

Before I show how to split, I have to deal with the common myths:

My solution isn't so big. It has only 10/20/100/100/X projects/classes inside

I cannot recommend how small one solution should be. I can agree that in some cases, 10 can be enough small, but I am sure that 50 is too much. I'm sure that when you open a solution, you will know that it is too big. But be fair with yourself.

I cannot split because we don't have enough test coverage

That is a very interesting myth. A split shouldn't make functional changes, so probably it won't break anything in the functional part of your system. Anyway, how do you test when you make new functionality? Automatically, manually, or using production users? In this case, do the same thing.

I don't see anything to separate

That's untrue, isn't it? For example, tools/utils can be separate, DTO, database projects, web projects, etc.

I don't have any dependency management

Maybe it's time to introduce it. Moreover, think about how you include external components. Can you build your stuff when the Internet is down? Aren't they a dependency management?
To introduce dependency management system, try just one library as a proof-of-concept.

My business owner/product manager/product owner won't accept spending time on this

Explain this: It won't take long, and after this change, we can develop more easily. We will spend some time now, but in the near future, we can work more quickly.

What if he doesn't understand? Maybe it's time to quit your job.

What's Next?

In near future, I will show how we can use ReSharper and Visual Studio to split your solution into smaller ones. Stay tuned.

Make your mark on the industry’s leading annual report. Fill out the State of API Integration 2019 Survey and receive $25 to the Cloud Elements store.

Topics:
dependency management ,monolith

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}