I'm sure you are familiar with the concept that one bounded context should map to one microservice. The rule is silently constructing the very thing that everyone says they despise. A monolith wearing a network for a costume.
The rule sounds right until you count the hops
Domain-Driven Design gave us bounded contexts. The definition of bounded context, separating a large domain in multiple sets of models, each with a specific definition and implication, was a blast of fresh air in a field with strong partiality to hardcode solutions at early design steps.
After that, a decision was made that each context should have its own deployment, its own repository, and its own on-call schedule. Dividing a domain into services does not eliminate the coupling between those parts, it simply shifts the coupling to the wire. A Java Code Geeks breakdown articulates this well: the simple one-context-per-service mapping results in a distributed monolith. It's the same hairball, but with even less-obvious failure modes.
The physics don't care about your architecture diagram
