Summary of "What Software Architecture Should Look Like • Dave Farley • GOTO 2022"

Core thesis

Software architecture should be evolutionary and pragmatic, not an all-knowing upfront blueprint. Treat architectural choices as experiments and guide the system by changing constraints (the “rules of the road”) as you learn. Architecture is the set of agreed constraints and shared understanding among developers that steer design and protect you from major mistakes — a snapshot that should be expected to change.

Key concepts and recommendations

Tourist map metaphor
- Maintain a lightweight, shared “map” of system structure and constraints to guide conversations, design decisions, and evolution.
Involve all developers
- Engage developers at every level in architecture discussions so shared understanding grows and decisions are applied consistently.
Architecture as containment of complexity
- Use bounded contexts, services, and modules to isolate concerns and enable independent evolution.
Cross-cutting concerns are first-class
- Treat security, scalability, resilience, performance, testability, deployability, and maintainability as system behaviours to be designed for and compartmentalized where possible.
Work incrementally and experimentally
- Make educated guesses, expose seams (areas of uncertainty), create crude prototypes/abstractions, and evolve the design as you learn.
Insulate known from unknown
- Avoid building full production solutions for uncertain areas early; design so you can enhance attributes (security, scalability, etc.) later without undoing prior work.
Reuse proven patterns when appropriate
- Use “off-the-shelf” architectures when the problem fits, but understand their constraints and trade-offs.
Beware tool-driven architecture
- Choosing technologies without understanding trade-offs (e.g., transactions, concurrency, coordination) can produce catastrophic design problems.
Microservices caution
- Microservices can be valuable for large organizations (independent deployability) but are often misapplied, resulting in distributed monoliths if services aren’t truly independently deployable.
Keep constraints few but clear
- Impose a small set of well-enforced constraints that provide guidance without blocking adaptation.

Illustrative examples and cautionary tales

Relational databases and transactions
- Transactions historically simplified multi-user concurrency; moving away from them for scale requires understanding the protections you lose.
NoSQL risks
- Using non-transactional stores without addressing concurrent writes can yield corrupt or nondeterministic state.
Misused microservices
- Teams may claim microservices while still requiring coordinated releases, adding complexity without delivering benefits.
Platform fragility
- Small platform-level changes (e.g., CPU optimizations) can invalidate major architectural assumptions — a reminder to respect underlying platform guarantees.
LMAX exchange
- The team took incremental, evolutionary steps across multiple core architectural attempts, limiting wasted effort on each change.

Practical “how-to” checklist

Start with reasonable guesses and treat them as falsifiable experiments.
Create and use a “tourist map” to make the current architecture explicit and communicable.
Identify seams and uncertainties early; sketch lightweight abstractions or prototypes for them.
Compartmentalize cross-cutting concerns and make these behaviours visible design goals.
Prefer iterative, incremental evolution over big upfront design — but do design something up front (no-design is not an answer).
Use proven architectures when they fit, but validate assumptions and constraints for your context.
If adopting microservices, ensure services/components are truly independently deployable.
Aim for a small set of rigid constraints the team respects; keep other areas flexible.