I've observed teams being formed to work on "microservices" that were designed upfront.

IMHO, It's not the optimal way to handle software development... Scaling simply to allocate tasks or for the sake of scaling leads to unnecessary tasks and wasted effort.

🤢In their initial six months, these repositories often contain more integration use cases than features focused on business users. Mainly technical code, a little to no business value.

💩Such practices are a prime factor behind the creation of complex distributed systems with inappropriate boundaries.

💢Incorrect boundaries divert focus from user needs, leading to "debugging hell," where teams spend days resolving technical issues, which grows frustration throughout the process.

💡A service with more integration-related methods than business-related ones strongly indicates a growing, distributed "big ball of mud."

😵‍💫Redesigning boundaries that were incorrectly set from the start is extremely challenging, if not impossible, as it involves altering the organization, infrastructure, and configuration.

💡A modular monolith is a more viable alternative. The decision to create microservices should be deferred, thoroughly evaluated, and challenged, given the severe risks of tight coupling.

"Finding service boundaries is really damn hard… There is no flowchart!" - Udi Dahan

Cheers 🍻

#software #DDD #strategicddd #craftsmanship #leanagile