🕵🏻‍♂️Detecting distributed ball of mud

A service with more integration-related methods/commands/events than business-related ones is a sign of a growing distributed big ball of mud.

❌Please stop trying to form squads to work on "micro services" designed upfront.

This approach doesn't work well in software development.
Scaling just for the sake of scaling or to assign tasks can lead to unnecessary efforts and tasks that aren't needed.

During the first 6 months, these modules usually contain more integration use cases than business-focused features, which can work in some simple cases, but often doesn't.

😱This is a common practice that leads to complex distributed systems with wrong boundaries.
These wrong boundaries can cause teams and products to lose focus on user needs and create debugging nightmares that cause frustration.

Wrong boundaries are difficult, if not impossible, to rework because it would require changing the structure, infrastructure, and configuration.

✅A modular monolith is always a better trade-off.

💡Before creating and isolating microservices, it's important to defer, prove, and challenge the need behind it because it represents a hard decision.

As Udi Dahan said, "Finding service boundaries is really damn hard... There is no flowchart!"

Cheers! 🍻

#microservices #softwaredevelopment #DDD