Previous post All-in-one model shows what is all-in-one model and why is bad. At the end we mention that this big model/class causes a lot of troubles. Let’s see why.

Imagine we are building software for selling products. The customer goes through below process steps to buy a product:

The process steps most likely will be implemented as modules/microservices. The system can look like that:

Customer data is passed from one microservice to next. Every microservice stores the Customer info in his database. Othe solution could be:

Every service read and write info about Customer in one place (microservice/database).

The same class and its data are used in many different modules/microservices! It is coupling, data coupling.

Imagine we have many all-in-one models and a large number of microservices. This system will be like this:

You can see a large number of dependencies (high coupling). Whatever architecture we come up with, e.g. asynchronous communication with CQRS or other, dependencies still exists either explicitly or implicitly. It is impossible to avoid them using any of technical/architectural solutions.

Sometimes you can see diagrams like that:

Excellent. But when you start to analyze, you find that the services communicate with each other multiple times for different purposes/data/ models especially for all-in-one models. It is not really one relationship, but many:

In every system, dependencies must exist. It is a natural way for services to communicate to do business processes. In this post, we are talking about systems with so many dependencies/communication that cause problems eg. to execute a business process hundreds of calls/events are made. This huge amount of communication is mainly due to bad system design.

Is it possible to avoid the problem of high coupling (huge amount of communication)? Yes, it is possible using models in contexts. Let’s see how to do this Model in the context