Learning Resources
This module is populated from the local chunked books in library/raw/semester-07-architecture-ddd/books. Use this page as a source map, not as an instruction to read everything. Open a chunk when a concept page points you there, not pre-emptively.
Source Stack
| Book | Role | How to use it in this module |
|---|---|---|
| Fundamentals of Software Architecture (Richards & Ford) | Primary teaching source | Default escalation for definitions of architecture, architect roles, characteristics (explicit/implicit), fitness functions, and tradeoff analysis |
| Just Enough Software Architecture (Fairbanks) | Secondary framing | Risk-driven model, architect's role, architecture description, models and views |
| Clean Architecture (Martin) | Selective | "What is architecture?" framing and the behavior vs. structure distinction |
| Learning Domain-Driven Design (Khononov) | Peripheral | Used sparingly for domain-framing language where Cluster 3 needs it |
| API Design Patterns (Geewax) | Out of scope | Used by Module 4, not here |
Resource Map by Cluster
Cluster 1: What Architecture Is
| Need | Best local chunk | Why |
|---|---|---|
| defining software architecture | Richards & Ford: Defining software architecture | Canonical definition and the "four dimensions" frame |
| architect's role / business domain | Richards & Ford: Have business domain knowledge | What architects do beyond drawing boxes |
| engineering practices expected | Richards & Ford: Engineering practices | The technical dimension of the role |
| operations / DevOps dimension | Richards & Ford: Operations - DevOps | Why the architect must own runtime concerns |
| thinking like an architect | Richards & Ford: Architectural thinking | Technical + strategic + communicator modes |
| balance: architect vs hands-on | Richards & Ford: Balancing architecture and hands-on coding | The "architecture vs code blur" in practice |
| what is software architecture (Fairbanks) | Fairbanks: What is software architecture | Second definition, different vocabulary |
| why architecture matters | Fairbanks: Why is software architecture important (1) | The "avoidable failures" argument |
| architect's job | Fairbanks: Architects architecting architectures | A compact framing of the architect role |
| clean architecture framing | Martin: The goal | Structure as "ability to keep changing software" |
| behavior vs structure | Martin: Behavior to fight for the architecture | The "urgent vs important" argument |
Cluster 2: Quality Attributes (the "-ilities")
| Need | Best local chunk | Why |
|---|---|---|
| architecture characteristics defined | Richards & Ford: Architecture characteristics defined | The definitional starting point |
| cross-cutting characteristics catalog | Richards & Ford: Cross-cutting architecture characteristics | The "-ilities" catalog; use as a lookup |
| measuring characteristics | Richards & Ford: Measuring architecture characteristics | Why measurable responses matter |
| measuring modularity | Richards & Ford: Measuring modularity | One example of operationalizing a characteristic |
| measuring modularity 2 | Richards & Ford: Measuring modularity 2 | Metrics like cohesion, coupling, connascence |
| tradeoff analysis as mindset | Richards & Ford: Analyzing trade-offs | Seeds the ATAM-style mindset |
Cluster 3: Architectural Characteristics in Practice
| Need | Best local chunk | Why |
|---|---|---|
| identifying characteristics | Richards & Ford: Identifying architectural characteristics | The canonical extraction routine |
| extracting from requirements | Richards & Ford: Extracting architecture characteristics from requirements | The practical workshop |
| explicit characteristics | Richards & Ford: Explicit characteristics | Stated requirements, written out as characteristics |
| implicit characteristics | Richards & Ford: Implicit characteristics | Domain-demanded but unstated; the hardest category |
| scope of characteristics | Richards & Ford: Scope of architecture characteristics | Where a characteristic lives in the system |
| fitness functions | Richards & Ford: Fitness functions | The canonical chapter on automated verification |
| characteristics case study | Richards & Ford: Going, going, gone case study | Worked extraction example |
| Khononov: characteristic lens on domains | Learning DDD: Distilling the problem domain | Use only when characteristic mapping pulls toward core/supporting subdomains |
Cluster 4: Architectural Tradeoffs
| Need | Best local chunk | Why |
|---|---|---|
| analyzing tradeoffs | Richards & Ford: Analyzing trade-offs | The first-law-of-architecture chapter |
| architectural thinking | Richards & Ford: Architectural thinking | Framing choices as tradeoffs, not best practices |
| characteristics ratings | Richards & Ford: Architecture characteristics ratings | First worked rating across styles; makes tradeoffs visible |
| monolithic vs distributed | Richards & Ford: Monolithic vs distributed architectures | The biggest recurring tradeoff in modern systems |
| risk-driven model | Fairbanks: Risk-driven model | Risk is the lens for prioritizing tradeoffs |
| project / engineering risks | Fairbanks: Project management risks, software engineering risks | Categorizing risk; separates architectural from process risk |
| guidance on choosing techniques | Fairbanks: Guidance on choosing techniques | Not "best practice" - decision-by-risk |
| planned vs evolutionary | Fairbanks: Planned and evolutionary design | Reversibility as a quality pre-stated |
| behavior vs structure tradeoff | Martin: Behavior to fight for the architecture | The "we shipped features; it's now unmaintainable" tradeoff |
Cluster 5: Communicating Architecture
| Need | Best local chunk | Why |
|---|---|---|
| team communication 1 | Fairbanks: Team communication part 1 | Audience-first framing |
| team communication 2 | Fairbanks: Team communication part 2 | Views, viewpoints, decomposition strategies |
| team communication 3 | Fairbanks: Team communication part 3 | Diagramming discipline and concerns |
| approach description | Fairbanks: Approach description | How Fairbanks models architecture artifacts |
| risk-driven model | Fairbanks: Risk-driven model | Which diagrams to draw when, driven by risk |
| business domain knowledge | Richards & Ford: Have business domain knowledge | Grounding communication in business reality |
| architecture characteristics (revisit) | Richards & Ford: Architecture characteristics defined | Communicating what the system optimizes for |
Exercise Support Chunks
Open these when concept pages are understood but you need more worked examples:
- Richards & Ford: Case study - Going, going, gone
- Richards & Ford: Case study - Silicon Sandwiches partitioning
- Richards & Ford: Case study - Going, going, gone - discovering components
- Fairbanks: Example - home media player
- Fairbanks: Integration of COTS components part 1
- Fairbanks: Integration of COTS components part 2
External Resources (Read-If-Curious)
Only use these if a concept page points to them, or you want a second exposition of the same idea. The module is completable from the local chunks alone.
- C4 Model for Software Architecture - Simon Brown's hierarchical diagramming approach (Context, Container, Component, Code). The reference for Cluster 5.
- C4 Model notation and legend - Canonical abstractions; use as legend reference on your own diagrams.
- arc42 template - A widely used architecture-documentation template covering context, constraints, building blocks, runtime, deployment, crosscutting concerns, decisions, quality, risks.
- arc42 overview - Short description of each section and how to fill it out.
- Developer to Architect (Mark Richards) - Podcast and video catalog from the author of Fundamentals of Software Architecture; short, focused episodes on roles, characteristics, and tradeoffs.
- Martin Fowler on Architecture - Index of Fowler's architecture writing; the definition-of-architecture essay and "Who Needs an Architect?" are the two to read first.
- Fowler: "Who Needs an Architect?" - Short PDF essay; the "hard to change" definition of architecture lives here.
- Continuous Architecture - Website for the Continuous Architecture in Practice book; useful for a modern, agile-compatible framing of architectural decisions.
- SEI on Quality Attribute Scenarios - Carnegie Mellon SEI introduction to ATAM-style quality attribute scenarios.
- Neal Ford on Fitness Functions - One of the clearest short explanations; pair with Richards & Ford chunk 022.
- 4+1 View Model (Kruchten) - The original 1995 paper; short, still worth reading once for historical context.
Use Rules
- If you are stuck on what counts as architectural, go to Richards & Ford chunk 004 and Fairbanks chunk 008.
- If you are stuck on "which characteristic is the top 3," the answer is in Richards & Ford chunks 017-020.
- If you are stuck on writing a fitness function, the answer is in Richards & Ford chunk 022.
- If you are stuck on tradeoff framing, Richards & Ford chunks 008 and 009 plus Fairbanks chunk 014 are the spine.
- If you are stuck on diagramming, go to C4 and arc42 first, then Fairbanks chunks 023-025.
- Open one chunk for one gap. Do not read chapter sequences by default.