With module 4.10 you decided how the code inside one of the Kladde's programs is cut: one style, measured against four others, recorded in an ADR and held in the build by architecture tests. Module 4.11 goes up one level. It no longer asks what the folders and projects of a program look like, but how a whole system is built: how many programs there are, where they run, how they talk to each other and which data they share. For this there are architecture styles, and this module covers them in breadth: styles, consistency models, cloud design patterns, replacing old systems, micro-frontends and checks that keep the architecture in the build.
The order has a reason. First you built one style in depth, the modular monolith from module 4.3, then you compared styles in code. Now comes the comparison of styles for whole systems, and only after that, in module 4.12, do you cut a real service out of the Kladde. Whoever knows the map sees why this one step pays off and most of the others don't.
This lesson draws the map. You get to know the six styles that Microsoft's Azure Architecture Center describes, plus two more that are not listed there as styles of their own. You see where microservices come from, namely from SOA and its enterprise service bus, and what went wrong there. And you measure what a call over the network costs, because that is the number at which many styles part ways. Nothing changes in the Kladde in this lesson.
Three earlier lessons carry this one. Lesson 4.1.2 wrote down quality goals with numbers and an order, among them the trade-off “more separation costs performance, in the extreme case over the network”. Lesson 4.2.5 introduced Conway's law. And lesson 4.3.6 decided in the ADR “Modules instead of microservices” that the Kladde is a modular monolith, with conditions under “Revisit when”.
What an architecture style is
Microsoft's documentation describes an architecture style as a family of architectures that share characteristics. A style does not prescribe a technology; some technology just fits it better than other technology, containers and microservices for instance. You should keep three levels apart:
| Level | Question | Examples | In this course |
|---|---|---|---|
| Architecture style | How is the whole system built, from which programs, and how do they talk to each other? | n-tier, microservices, event-driven | this module |
| Code architecture | How is the code inside one program cut? | layers, hexagonal, vertical slice | module 4.10 |
| Design pattern | How do you solve a specific, recurring problem? | outbox, circuit breaker, cache-aside | module 4.6, lesson 4.11.5 |
The most important thing about a style is its constraints. A style fixes which building blocks may exist and how they may relate to each other. Whoever keeps to these constraints gets certain properties in return. Microsoft gives the constraints of microservices as an example:
- A service has a single responsibility.
- Every service is independent of the others.
- Data belongs to the service that owns it; services do not share data.
From this follows what you gain: deploying services independently, containing failures, deploying more often, adopting new technology more easily. If you break a constraint, say because two services do share a table after all, the property it carried is gone: The two services can then no longer be deployed independently.
Microsoft's advice on choosing fits what you did in module 4.1. First understand the problem, then determine and rank the quality goals, then choose the style that supports them. And: look more at why you choose a style than at how you implement it. Whoever does not know the reasons easily builds something that looks like the style from the outside and has none of its advantages. Sometimes it is better to loosen a constraint than to chase a pure doctrine.