From the Masters
Ideas distilled from Martin Fowler, Gregor Hohpe, Eric Evans, Michael Nygard, Fred Brooks, Kent Beck, David Parnas, Werner Vogels, Neal Ford, and Mark Richards. Each is attributed to its source so you can go back to the original.
- No. 112
The Architect Elevator
Ride between the penthouse and the engine room: connect business strategy with technical reality.
- No. 113
Architects See More Dimensions
Many either-or conflicts dissolve once you add a dimension the debaters are not seeing.
- No. 114
Starbucks Does Not Use Two-Phase Commit
Real businesses scale through asynchronous, compensating processes, not distributed transactions.
- No. 115
Economies of Speed
Digital organisations win by how quickly they can learn and change, not by how big they are.
- No. 116
Architecture Is About the Important Stuff
Architecture is the set of decisions that are hard to change, whatever those turn out to be.
- No. 117
Monolith First
Start with a well-structured monolith; split into services only once the boundaries and the need are proven.
- No. 118
Microservice Premium
Microservices carry a fixed overhead that only pays off above a certain level of complexity.
- No. 119
Sacrificial Architecture
Design knowing you may throw the system away, and treat that as a sign of success.
- No. 120
Design Stamina Hypothesis
Good internal design slows you briefly; past the payoff line it is what keeps you fast.
- No. 121
Technical Debt Quadrant
Classify debt as deliberate or inadvertent, and prudent or reckless; each needs a different response.
- No. 122
Anti-Corruption Layer
Protect your domain model by translating at the boundary with systems whose models you don't control.
- No. 123
Architecture Decision Records
Capture the why behind significant decisions in short, immutable records future teams can read.
- No. 124
Circuit Breaker
Stop calling a failing dependency for a while, so its failure doesn't become yours.
- No. 125
Why Is More Important Than How
The second law of software architecture: a design only makes sense once you know why it was chosen.
- No. 126
Conceptual Integrity
A system should reflect one coherent set of design ideas, even at the cost of some features.
- No. 127
Everything Fails, All the Time
At scale, failure is the normal state. Design for it rather than hoping to prevent it.
- No. 128
Make the Change Easy, Then Make the Easy Change
When a change is hard, first reshape the system so the change becomes easy.
- No. 129
Information Hiding
Decompose systems around the decisions most likely to change, and hide each behind an interface.