In the last lesson you renewed your decision “Modules instead of microservices” with numbers: programs, pipelines, network calls in
the most important flows, the time of one call and the number of people. It stood. This lesson asks the question the other way round. Not
“why no microservices?”, but: What would have to happen for a service of its own to pay off? And for each module of the Kladde individually.
The answer ends up as a table in docs/, and in module 4.12 the first candidate from it really moves into a service of its own.
Four earlier lessons carry this one. Lesson 4.1.1 described architecture as the decisions that are hard to reverse. Lesson 4.2.5 introduced Conway's law and the inverse Conway maneuver. Lesson 4.3.6 built the Kladde as a modular monolith and said that the path into a service stays open as long as modules know each other only through contracts. And module 4.6 showed that a message arrives at least once, that an outbox gets it out safely and that a receiver has to recognize duplicates.
A module and a service have the same boundaries
First, what stays the same. A module of the Kladde and a microservice share the things that are hard to get: a bounded context, a model of its own, a contract to the outside, data of its own. Microsoft's guide to service boundaries therefore begins exactly where you started in module 4.2: A service should not span more than one bounded context, and aggregates are good candidates for the boundary.
The difference lies in how the boundary is enforced:
| Module | Service | |
|---|---|---|
| Boundary enforced by | compiler and architecture test | process and network |
| a call across the boundary | method call or event in the process | HTTP, gRPC or message |
| delivered | with all the others | on its own |
| scaled | with all the others | on its own |
| fails | with all the others | on its own, if the others are prepared for it |
The last three rows are what a service gains. The second row is its price. That price comes first.