Everything is a monolith

Software development, in a nutshell, is about coupling management.

We set project rules and make boundaries to cut down on coupling. Why?

To minimise the intertwining of responsibilities, which eventually brings many benefits, e.g. reducing the necessity of communication between teams/developers, improving fault tolerance, shortening deployability time, avoiding conflicts in changes or strengthening evolvability.

We deploy a set of separate services isolated from dedicated databases.

We add a queue to exchange asynchronous messages and, again, to improve reliability.

But despite all the effort, we still developed a monolith system—the same one that was poorly written, full of god classes with spaghetti code, where the coupling is a permanent resident.

Despite the effort of making a perfectly designed context, those contexts still have to talk to each other to meet business goals.

The thing is that the services, contexts or modules will be in an eventual coupling at some point. They will need to pass their results and wait for some events.

Think of cooperating contexts like ShoppingCart, Inventory, Order, PurchaseOrder, Payments, and Invoices. Together, they provide value and give a business capability, which is the possibility of making orders.

We don’t manage coupling to craft something other than a monolith; we manage coupling to make that monolith evolvable and, therefore, less expensive in development.