Reference and Selective Reading
You do not need to read the source books front-to-back for this module. Use the concept pages and practice pages first. Open these local chunks only when you need alternate exposition, more worked examples, or a deeper exercise lane.
Source Roles
| Source | Role | Why it is here |
|---|---|---|
| Fundamentals of Software Architecture (Richards, Ford) | Primary teaching source | Best operational material on ADRs, fitness functions, risk, and team practice |
| Just Enough Software Architecture (Fairbanks) | Primary on risk-driven review | Strongest framing of risk-driven evaluation and architectural mismatch |
| Clean Architecture (Martin) | Peripheral | Background philosophy of architectural concerns; rarely needed here |
| Learning Domain-Driven Design (Khononov) | Peripheral | Useful when the architectural / design-decision boundary collides with bounded contexts |
| API Design Patterns (Geewax) | Peripheral | Public API ADR examples; one-way-door decisions in practice |
Read Only If Stuck
Cluster 1: Architecture Decisions as Artifacts
- Fundamentals: Defining software architecture
- Fundamentals: Architectural thinking
- Fundamentals: Analyzing trade-offs
- Fundamentals: Architecture decisions
- Just Enough: Software architecture
- Just Enough: Why is software architecture important (part 1)
- Just Enough: Why is software architecture important (part 2)
- Just Enough: Make rational architecture choices
- Just Enough: Risk-driven model
Cluster 2: ADR Mechanics
- Fundamentals: Basic structure (ADR)
- Fundamentals: Architecture decision records
- Fundamentals: Analyzing trade-offs
- Just Enough: Team communication (part 1)
- Just Enough: Team communication (part 2)
Cluster 3: Architecture Review Methods
- Just Enough: Risk-driven model
- Just Enough: PM risks vs SE risks
- Just Enough: Guidance on choosing techniques
- Just Enough: Planned and evolutionary design
- Just Enough: Features and risk - a story
- Just Enough: Quality attribute scenarios
- Just Enough: Analyzing architecture models (part 1)
- Just Enough: Analyzing architecture models (part 2)
- Fundamentals: Risk matrix
- Fundamentals: Making teams effective
Cluster 4: Running Architecture Reviews in Practice
- Fundamentals: Making teams effective
- Fundamentals: Team warning signs
- Fundamentals: Leveraging checklists
- Fundamentals: Negotiation and facilitation
- Fundamentals: Negotiating with other architects
- Fundamentals: The software architect as a leader
- Fundamentals: Leading teams by example
- Fundamentals: Risk storming
- Fundamentals: Risk storming examples
- Just Enough: Team communication (part 3)
Cluster 5: Architecture Decisions Over Time
- Fundamentals: Measuring architecture characteristics
- Fundamentals: Fitness functions
- Fundamentals: Integrating with the development team
- Fundamentals: Developing a career path
- Just Enough: Architectural mismatch
- Just Enough: Challenges (part 1)
- Just Enough: Challenges (part 2)
Optional Deep Dive
- Fundamentals: Diagramming and presenting architecture - how to present the decision context visually
- Fundamentals: Diagram guidelines - keep review diagrams legible
- Fundamentals: Armchair architect - anti-pattern of reviewing without implementing
- Fundamentals: Consensus - when to push past consensus-seeking
- Fundamentals: Thoughtworks Technology Radar - a related artifact format
- Just Enough: Application to an agile process - integrating review into iterative delivery
Concept-to-Source Map
| Primary concept | Best source if stuck | Why this source |
|---|---|---|
| Architecture vs design decision | Fundamentals: Architecture decisions | Directly on the boundary question |
| Why decisions need to be recorded | Fundamentals: Architecture decision records | Primary rationale for ADRs |
| Reversibility (one-way vs two-way) | Just Enough: Risk-driven model | Risk-language equivalent of the doors |
| ADR templates | Fundamentals: Basic structure | Template scaffolding |
| Context, decision, consequences | Fundamentals: Analyzing trade-offs | Real consequences with tradeoffs |
| Status lifecycle and superseding | Fundamentals: Architecture decision records | Lifecycle conventions |
| ATAM sketch | Just Enough: Quality attribute scenarios | Scenario shape for utility trees |
| Risk-driven review (RCDA) | Just Enough: Risk-driven model | Primary source |
| Lightweight peer review | Fundamentals: Making teams effective | Review culture and cadence |
| Preparing a review | Fundamentals: Leveraging checklists | Checklist-based packages |
| Facilitation | Fundamentals: Negotiation and facilitation | Curiosity vs judgment in practice |
| Outputs: decisions, followups, risks | Fundamentals: Risk matrix | How to capture risks durably |
| Fitness functions | Fundamentals: Fitness functions | Primary treatment |
| Architectural drift | Just Enough: Architectural mismatch | Drift as a first-class concern |
| Architecture guild | Fundamentals: Integrating with the development team | Team practice sustainability |