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

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.

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.

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.

Topics:
dependency management ,monolith

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

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

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.

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}