Architecture Basic
“The code is a mess, should we split into microservices?” mixes two problems. Code organization and the deployment unit are two independent axes: a single deployment can still have clean modules, and many services can still be tightly coupled if they always have to deploy together.
Reading path
Section titled “Reading path”| Order | Article | Question it answers |
|---|---|---|
| 1 | Monolith, modular monolith, microservices | Should you split processes yet? Which measurable signals matter? How do you enforce module boundaries? |
| 2 | Bounded context | Where does a model stay consistent? Which patterns connect contexts? |
| 3 | Hexagonal & clean architecture | When is it worth separating the business core from the framework? Ports, adapters, the dependency rule, and the cost? |
| 4 | CQRS and event sourcing | When do separate read models pay off, and when is event sourcing worth its cost? How do projections, snapshots and erasure work? |
Two complementary articles
Section titled “Two complementary articles”- Article 1 asks “how many deployments” and gives a comparison table of the three architecture styles plus the decision signals (co-change, deploy waits, uneven load).
- Article 2 asks “where is the model boundary”: it separates subdomain from bounded context, draws a context map, and separates Published Language (upstream side) from the ACL (downstream side).
Related reading
Section titled “Related reading”- Adapter pattern: how to implement the translation layer (ACL) at an integration boundary.
- Strategy pattern: isolating what varies at a smaller scale.
- Eight fallacies of distributed computing: the assumptions that break when an in-process call becomes a network call.
- Transactional outbox: publishing events in the same transaction when crossing a boundary.