Learning Resources

This generated surface maps a learner-facing curriculum unit to its canonical source routes.

Curriculum surface

• Open learner-facing unit
• Curriculum path: content/curriculum/architecture/semester-07-architecture-ddd/module-01-architecture-fundamentals-quality/resources.md
• App: architecture
• Semester: semester-07-architecture-ddd
• Module: module-01-architecture-fundamentals-quality
• Unit kind: resource
• Curation level: module_curated

Learning objectives

• Explain Learning Resources in terms of architectural scope, quality attributes, and tradeoffs instead of slogans about “good design.”
• Use Learning Resources to reason about why certain decisions become expensive to reverse as systems and teams grow.
• Use clean-architecture, fundamentals-of-software-architecture, just-enough-software-architecture, learning-domain-driven-design to connect the learner-facing explanation to concrete architecture characteristics, scenarios, and decision framing.

Prerequisites

• Comfort with systems, databases, and the idea that different design choices create different operational tradeoffs.

Source books

• clean-architecture
• fundamentals-of-software-architecture
• just-enough-software-architecture
• learning-domain-driven-design

Source routes

Clean Architecture

• /books/clean-architecture via Martin: Behavior to fight for the architecture, Martin: The goal

Fundamentals Of Software Architecture

• /books/fundamentals-of-software-architecture via Richards & Ford: Analyzing trade-offs, Richards & Ford: Architectural thinking, Richards & Ford: Architecture characteristics defined, Richards & Ford: Architecture characteristics ratings, Richards & Ford: Balancing architecture and hands-on coding, Richards & Ford: Case study - Going, going, gone, Richards & Ford: Case study - Going, going, gone - discovering components, Richards & Ford: Case study - Silicon Sandwiches partitioning, Richards & Ford: Cross-cutting architecture characteristics, Richards & Ford: Defining software architecture, Richards & Ford: Engineering practices, Richards & Ford: Explicit characteristics, Richards & Ford: Extracting architecture characteristics from requirements, Richards & Ford: Fitness functions, Richards & Ford: Going, going, gone case study, Richards & Ford: Have business domain knowledge, Richards & Ford: Identifying architectural characteristics, Richards & Ford: Implicit characteristics, Richards & Ford: Measuring architecture characteristics, Richards & Ford: Measuring modularity, Richards & Ford: Measuring modularity 2, Richards & Ford: Monolithic vs distributed architectures, Richards & Ford: Operations - DevOps, Richards & Ford: Scope of architecture characteristics

Just Enough Software Architecture

• /books/just-enough-software-architecture/chapter-03-architects-architecting-architectures via Fairbanks: Architects architecting architectures
• /books/just-enough-software-architecture/chapter-05-what-is-software-architecture via Fairbanks: What is software architecture
• /books/just-enough-software-architecture/chapter-06-why-is-software-architecture-important-part via Fairbanks: Why is software architecture important (1)
• /books/just-enough-software-architecture/chapter-08-approach-description via Fairbanks: Approach description
• /books/just-enough-software-architecture/chapter-09-risk-driven-model via Fairbanks: Risk-driven model
• /books/just-enough-software-architecture/chapter-10-project-management-risks-software-engineering-risks via Fairbanks: Project management risks, software engineering risks
• /books/just-enough-software-architecture/chapter-11-guidance-on-choosing-techniques via Fairbanks: Guidance on choosing techniques
• /books/just-enough-software-architecture/chapter-12-planned-and-evolutionary-design via Fairbanks: Planned and evolutionary design
• /books/just-enough-software-architecture/chapter-15-example-home-media-player via Fairbanks: Example - home media player
• /books/just-enough-software-architecture/chapter-16-team-communication-part via Fairbanks: Team communication part 1, Fairbanks: Team communication part 2, Fairbanks: Team communication part 3
• /books/just-enough-software-architecture/chapter-17-integration-of-cots-components-part via Fairbanks: Integration of COTS components part 1, Fairbanks: Integration of COTS components part 2

Learning Domain Driven Design

• /books/learning-domain-driven-design via Learning DDD: Distilling the problem domain

Supporting curriculum routes

No supporting curriculum routes linked yet.

External enrichment

• Martin Fowler: Evolutionary Architecture and Fitness Functions (optional_deep_dive) - Connects architecture characteristics to measurable, evolving constraints in real systems.
• SEI Quality Attribute Workshop (official_docs_companion) - Provides a disciplined way to think about quality-attribute scenarios and architectural reasoning.

AI companion modes

• Explain simply
• Diagnose my confusion
• Revision mode
• Connect forward / backward

Source-of-truth note

This teaching unit is learner-facing guidance assembled from multiple canonical book routes. Use the listed source books as the primary conceptual spine for Learning Resources, and treat outside material as supporting enrichment only.