Nowadays, many software applications and systems are so complex (huge number of requirements) that without the proper designing developers very fast build a big ball of mud – a common term in IT. The term, I think, does not reflect the amount and weight of problems, so I call it hell.

Maybe you are working with such a hellish system/application like this

where the number of communications is huge, many dependencies (high coupling) and simple functionalities goes through many modules/services.

Where do these “imperfect” systems come from? The main reason is wrong design of boundaries. Let me explain with an example.

Take a look at properly designed system

The three services interact with each other, the number of communications is small. Most of the interactions (lines) are inside the service (interactions between classes). Excellent.

Now we are removing the boundaries

and we randomly set the boundaries of microservices

In that case, microservices are big – do many things, and have many responsibilities, so they become a monolithic system with a big mess inside. Do you like monolithic systems? No, I either, so maybe this way:

Hmm. Do you see what happened? More services and a lot of communication between them. Not good. Very bad. This is because we have set the boundaries in the wrong places. Maybe it reminds you of something? …. Exactly:

Welcome in hell of dependencies.

This is exactly what happens when we randomly create microservices without paying attention to the proper boundaries, or when the boundaries are poorly defined. In such a system, you will run into a lot of serious problems mentioned here: What’s wrong with my microservices?

Maybe you’re wondering how to properly define service boundaries to avoid dependency hell? You can find answer here: Well-designed system starts with domains