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. This page is the "Read This Only If Stuck" registry that the concept pages link to.

Source Roles

Source	Role	Why it is here
Fundamentals of Software Architecture (Richards, Ford)	Primary teaching source	Best operational treatment of what architecture is, architectural characteristics (explicit / implicit), fitness functions, and tradeoff framing
Just Enough Software Architecture (Fairbanks)	Primary on models, risk, communication	Strongest framing of risk-driven design, architectural modeling, and team communication
Clean Architecture (Martin)	Selective	"Fight for the architecture" framing; behavior vs structure; used for Cluster 1 motivation
Learning Domain-Driven Design (Khononov)	Peripheral	Useful only when characteristic extraction collides with subdomain framing
API Design Patterns (Geewax)	Out of scope	Covered in Module 4

Read Only If Stuck

Cluster 1: What Architecture Is

• Fundamentals: Defining software architecture
• Fundamentals: Architectural thinking
• Fundamentals: Balancing architecture and hands-on coding
• Fundamentals: Have business domain knowledge
• Fundamentals: Engineering practices
• Fundamentals: Operations - DevOps
• Just Enough: What is software architecture
• Just Enough: Why is software architecture important (part 1)
• Just Enough: Architects architecting architectures
• Clean: The goal
• Clean: Behavior to fight for the architecture

Cluster 2: Quality Attributes (the "-ilities")

• Fundamentals: Architecture characteristics defined
• Fundamentals: Cross-cutting architecture characteristics
• Fundamentals: Measuring architecture characteristics
• Fundamentals: Analyzing trade-offs
• Fundamentals: Measuring modularity
• Fundamentals: Measuring modularity 2
• Fundamentals: Connascence

Cluster 3: Architectural Characteristics in Practice

• Fundamentals: Identifying architectural characteristics
• Fundamentals: Extracting characteristics from requirements
• Fundamentals: Explicit characteristics
• Fundamentals: Implicit characteristics
• Fundamentals: Scope of architecture characteristics
• Fundamentals: Going, going, gone case study
• Fundamentals: Fitness functions

Cluster 4: Architectural Tradeoffs

• Fundamentals: Analyzing trade-offs
• Fundamentals: Architectural thinking
• Fundamentals: Architecture characteristics ratings
• Fundamentals: Monolithic vs distributed architectures
• Just Enough: Risk-driven model
• Just Enough: PM risks vs SE risks
• Just Enough: Guidance on choosing techniques
• Just Enough: Planned and evolutionary design

Cluster 5: Communicating Architecture

• Just Enough: Team communication (part 1)
• Just Enough: Team communication (part 2)
• Just Enough: Team communication (part 3)
• Just Enough: Approach description
• Just Enough: Risk-driven model
• Fundamentals: Architectural thinking

Optional Deep Dive

• Fundamentals: Have business domain knowledge - the role of domain knowledge in architectural reasoning
• Fundamentals: Engineering practices - the technical-dimension expectations of architects
• Fundamentals: Operations - DevOps - why runtime matters to architecture, not just structure
• Fundamentals: Modularity - the single most important structural characteristic to reason about
• Fundamentals: Case study - Silicon Sandwiches partitioning - worked example of structural partitioning decisions
• Fundamentals: Discovering components - moving from characteristics to structure
• Fundamentals: Case study - Going, going, gone - discovering components
• Fairbanks: Example - home media player - compact worked system example
• Fairbanks: Integration of COTS components (part 1)
• Fairbanks: Integration of COTS components (part 2)

Concept-to-Source Map

Primary concept	Best source if stuck	Why this source
Architecture = structure + hard-to-change decisions	Fundamentals: Defining software architecture	Canonical definition
Architect roles (technical, strategic, communicator)	Fundamentals: Architectural thinking	The three modes named explicitly
Architecture vs design vs code	Fundamentals: Balancing architecture and hands-on coding	Where the blur line is in practice
Functional vs quality requirements, ATAM mindset	Fundamentals: Architecture characteristics defined	Definition + motivation for scenarios
Operational qualities (perf, scale, avail, reliability)	Fundamentals: Cross-cutting architecture characteristics	Catalog with distinctions
Evolutionary qualities (mod, test, deploy)	Fundamentals: Cross-cutting architecture characteristics	Same catalog, different cluster
Identifying characteristics from requirements	Fundamentals: Extracting characteristics from requirements	The practical extraction routine
Explicit vs implicit, top-3 rule	Fundamentals: Implicit characteristics	Implicit is the hard category
Fitness functions	Fundamentals: Fitness functions	Primary treatment
No right answers, only tradeoffs	Fundamentals: Analyzing trade-offs	First-law-of-architecture chapter
Common tradeoff pairs	Fundamentals: Architecture characteristics ratings	First ratings exercise - shows pairs in action
Cost of decisions, reversibility	Just Enough: Planned and evolutionary design	Decision-over-time framing
Views and viewpoints (C4, 4+1, arc42)	Just Enough: Team communication (part 2)	Views and viewpoints grounding
Diagramming discipline	Just Enough: Team communication (part 3)	Diagramming discipline and concerns
Architectural risk and first principles	Just Enough: Risk-driven model	Risk as the decision lens

External Community References

• C4 Model for Software Architecture
• arc42 template
• Developer to Architect (Mark Richards)
• Martin Fowler on Architecture
• Fowler: "Who Needs an Architect?" (PDF)
• Continuous Architecture
• SEI on Quality Attribute Scenarios (PDF)
• Thoughtworks: Fitness Function-Driven Development
• 4+1 View Model (Kruchten PDF)
• Fowler: Foreword to Building Evolutionary Architectures