Module 1: Architecture Fundamentals & Quality Attributes

Primary text: Fundamentals of Software Architecture (Richards & Ford)
Selective support: Clean Architecture (Martin) for the "hard to change" framing; Just Enough Software Architecture (Fairbanks) for risk-driven and quality-attribute scenarios; Learning Domain-Driven Design (Khononov) only where domain framing sharpens a characteristic

This guide is the primary teacher. You do not need to read the source books front-to-back to complete this module. You do need to leave the module able to name what architecture is in a working system, pull the top three architectural characteristics out of a messy requirements document, and defend them as tradeoffs rather than virtues.

Scope of This Module

This module is the one where "architecture" stops being a slogan. It is not about picking patterns. It is about making the forces a system must respond to explicit, then deciding what to spend.

What it covers in depth:

what architecture actually is: the structure and the decisions that are hard to change
who "the architect" is and what the role looks like in technical, strategic, and communicator modes
the blur between architecture, design, and code, and why pretending the line is sharp costs time
the difference between functional requirements and quality requirements (the -ilities)
operational qualities: performance, scalability, availability, reliability
evolutionary qualities: modifiability, testability, deployability
extracting architectural characteristics from a real requirements document
explicit vs implicit characteristics, and the "top three" rule as a forcing function
measuring characteristics with fitness functions that run in CI
the "no right answers, only tradeoffs" stance, with concrete tradeoff pairs
the cost of architectural decisions and reversibility treated as its own quality
views and viewpoints: C4, 4+1, and arc42 as different answers to the same question
diagramming discipline: why boxes-and-lines diagrams deceive, and how to draw one that does not
architectural risk, first principles, and where the real source of confidence comes from

What it deliberately does not cover:

concrete architecture styles (layered, hexagonal, microservices, event-driven) - that is Module 2
domain modeling, bounded contexts, and ubiquitous language - Module 3
API contracts and evolution - Module 4
ADRs as artifacts and architecture reviews - Module 5
team topologies and org-scale architecture governance - later semesters

This module is a foundation. If you can quote the words "fitness function" but not write one for a real characteristic, the module is not complete.

Before You Start

Answer these closed-book before starting the main path:

What is one decision from your last project that would have been genuinely expensive to reverse six months later? What made it expensive?
A stakeholder says "the new system should be scalable and secure." What three questions do you ask before that becomes a requirement?
Name three quality attributes that might conflict with each other. For each pair, describe a concrete conflict.
What is the difference between "the system supports SSO" and "99.9% of login requests complete in under 500 ms"?
Your team draws a box labelled "service" with a line to another box labelled "database." What does an outsider actually learn from that diagram?

Diagnostic Interpretation

4-5 solid answers - Ready for the full path. Move on.
2-3 solid answers - Continue, but expect extra time in Clusters 3 and 4.
0-1 solid answers - You have probably never been on the hook for an expensive architecture decision. The module will still work, but be honest in the drills: pick a system you actually know.

What This Module Is For

Every later module in this semester (patterns, DDD, APIs, ADRs) assumes you already know what architecture is and what it is trying to optimize. If you skip that foundation, each subsequent module decays into pattern memorization.

Throughout the program and in real work, you will be asked:

"should we use microservices?" - which is the wrong question until you can name the characteristics at stake
"why is the system so hard to change?" - which is usually an evolutionary-qualities question nobody asked at the start
"can you review this design?" - which has no meaning without an explicit list of characteristics to review against
"we had an outage, what went wrong architecturally?" - which is a reversibility and risk question

This module builds the language and reflexes needed to answer those without hand-waving.

Concept Map

How To Use This Module

Work in order. Clusters 3-5 only make sense once Clusters 1-2 have given you the vocabulary.

Cluster 1: What Architecture Is

Order	Concept	Type	Focus
1	Architecture Is Structure Plus Decisions That Are Hard to Change	PRIMARY	Structure + hard-to-reverse decisions as the working definition
2	The Architect Role: Technical, Strategic, Communicator	PRIMARY	The three modes any architect has to operate in
3	Architecture vs Design vs Code: The Blur Line	SUPPORTING	Why the boundary moves and how to work with the blur

Cluster mastery check: Can you name one decision from a system you know that is architectural, one that is design, and explain what test you applied?

Cluster 2: Quality Attributes (The `-ilities`)

Order	Concept	Type	Focus
4	Functional vs Quality Requirements: The ATAM Mindset	PRIMARY	The difference between "what it does" and "how well it has to do it"
5	Operational Qualities: Performance, Scalability, Availability, Reliability	PRIMARY	Qualities the system must demonstrate while it is running
6	Evolutionary Qualities: Modifiability, Testability, Deployability	PRIMARY	Qualities the system must demonstrate while it is changing

Cluster mastery check: Given the phrase "the system should be fast, reliable, and easy to change," can you rewrite it as three scenarios with measurable responses?

Cluster 3: Architectural Characteristics in Practice

Order	Concept	Type	Focus
7	Identifying Architectural Characteristics from Requirements	PRIMARY	Pulling characteristics out of a requirements document
8	Explicit vs Implicit Characteristics, and the Top-Three Rule	PRIMARY	What nobody wrote down, and why trying to win at everything loses
9	Measuring Fitness Functions for Characteristics	PRIMARY	Turning characteristics into automated, running tests

Cluster mastery check: Given a two-page requirements document you have not seen before, can you produce the top-3 characteristics, justify each, and write a fitness function for at least one?

Cluster 4: Architectural Tradeoffs

Order	Concept	Type	Focus
10	There Are No Right Answers, Only Tradeoffs	PRIMARY	The only universal principle of architecture
11	Common Tradeoff Pairs: Consistency↔Availability, Simplicity↔Flexibility	PRIMARY	The named pairs that show up in every real system
12	The Cost of Architectural Decisions: Reversibility as a Quality	PRIMARY	Treating reversibility itself as something to optimize for

Cluster mastery check: Given a proposed architecture move (e.g., "split service X into two"), can you name what it buys, what it spends, and whether you could undo it later?

Cluster 5: Communicating Architecture

Order	Concept	Type	Focus
13	Views and Viewpoints: C4, 4+1, arc42	SUPPORTING	Different frames on the same system, and when each helps
14	Diagramming Discipline: Boxes-and-Lines vs Meaningful	PRIMARY	Why most architecture diagrams lie, and how to draw one that does not
15	Architectural Risk and the Importance of First Principles	PRIMARY	Risk storming, unknown unknowns, and going back to the ground

Cluster mastery check: Pick a system you know. Can you draw its C4 Context diagram, its Container diagram, and name the two biggest architectural risks it carries?

Then work these practice pages:

Order	Practice path	Focus
1	Quality Attributes Elicitation Lab	Turning stakeholder language into measurable scenarios
2	Characteristics-from-Requirements Workshop	Pulling the top three characteristics out of real docs
3	Tradeoff Analysis Clinic	Defending architecture moves as explicit tradeoffs
4	Architecture Communication Katas	C4 diagrams, critique, and fitness-function writing, timed

Use Module Quiz after the concept and practice path. Use Reference and Selective Reading and Learning Resources for targeted reinforcement.

Learning Objectives

By the end of this module you should be able to:

Define architecture as structure plus decisions that are hard to change, and apply the definition to classify a real decision.
Describe the architect role in three modes: technical depth, strategic direction, and communication, and explain when each dominates.
Distinguish a functional requirement from an architectural characteristic, and rewrite vague quality language as measurable scenarios.
Name and define the core operational qualities (performance, scalability, availability, reliability) and evolutionary qualities (modifiability, testability, deployability), and compare them in pairs that conflict.
Read an unfamiliar requirements document and produce a defensible list of the top three architectural characteristics with reasoning.
Tell explicit from implicit characteristics and explain why the top-three rule protects systems from characteristic sprawl.
Write at least one fitness function that runs as an automated test for a given characteristic.
State the tradeoff-first stance on architecture ("no right answers, only tradeoffs") and defend a chosen architecture move in terms of what it buys and what it spends.
Classify common tradeoff pairs (consistency vs availability, simplicity vs flexibility, performance vs modifiability, cost vs any other) in a concrete system.
Treat reversibility as its own quality: classify a decision as one-way or two-way, and match the review weight to the class.
Sketch C4 Context and Container diagrams for a system, and critique a boxes-and-lines diagram by naming what it fails to communicate.
Identify the top architectural risks of a system using a first-principles check: what are the real sources of confidence, and what could destroy them?

Outputs

one two-page writeup for a system you know, stating "what is architectural here and why" using the hard-to-change test
a quality-attribute scenario sheet with at least 8 scenarios covering both operational and evolutionary qualities
one characteristics-from-requirements exercise on a two-page brief you did not author, producing the top-3 with justification
at least 3 fitness functions: one performance, one modifiability, and one you pick, each with the runnable assertion and the signal it produces
one tradeoff matrix for a real or realistic architecture move (e.g., "adopt event-driven between two services"): benefits, costs, and the quality each lands on
one reversibility register for at least 8 decisions in a system, each labelled one-way or two-way with justification
one C4 Context and Container diagram pair for a system, plus a critique of someone else's boxes-and-lines diagram
one risk register of 5-10 architectural risks using a first-principles check, with the assumption each risk would invalidate
a mistake journal naming at least 8 recurring architectural reasoning errors (confused scalability with performance, top-5 characteristics that nobody can defend, fitness function that never runs, tradeoff claim with no cost named, etc.)

Completion Standard

You have completed Module 1 when all of these are true:

you can state, in one sentence, what makes a decision architectural, and apply the sentence to a real example
you can rewrite "the system should be fast" as a measurable scenario without looking up the template
you can name the top three architectural characteristics of a system and defend each with one sentence
you can write a fitness function that runs and asserts against a characteristic
you can name what any proposed architecture move spends, not only what it buys
you can classify a decision as one-way or two-way and match the review weight accordingly
you can critique a diagram by naming what the viewer cannot conclude from it
you can name at least three architectural risks of a system you have never designed

If you can define the terms but cannot produce the artifacts, the module is not complete.

Reading Policy

Concept pages are the main path.
Fundamentals of Software Architecture chunks are the primary selective reinforcement.
Clean Architecture chunks 1-6 and Just Enough Software Architecture are used only where they sharpen a specific idea (the "hard to change" framing, risk-driven design).
External URLs (c4model.com, arc42.org, developertoarchitect.com, martinfowler.com, continuousarchitecture.com) appear in resources.md and are cited inline where they strictly add something the books do not.
Read only if stuck means try the concept page, self-check, and drill first.
Written artifacts (scenarios, fitness functions, tradeoff matrices, diagrams) are required deliverables, not optional enrichment.

Suggested Weekly Flow

Day	Work
1	Concepts 1-3 and one "what's architectural here" writeup for a system you know
2	Concepts 4-6 and 8 quality-attribute scenarios across operational and evolutionary
3	Concepts 7-8 and the Characteristics-from-Requirements Workshop
4	Concept 9 and the first 3 fitness functions, at least one running in CI
5	Concepts 10-12 and the Tradeoff Analysis Clinic
6	Concepts 13-14 and the first C4 Context + Container diagram
7	Concept 15, Practice 4 (communication katas), quiz, mistake-journal cleanup

Reference

If you need exact links into the local chunked books, use Reference and Selective Reading.

Rich Learning Pages

Scope of This Module​

Before You Start​

Diagnostic Interpretation​

What This Module Is For​

Concept Map​

How To Use This Module​

Cluster 1: What Architecture Is​

Cluster 2: Quality Attributes (The -ilities)​

Cluster 3: Architectural Characteristics in Practice​

Cluster 4: Architectural Tradeoffs​

Cluster 5: Communicating Architecture​

Learning Objectives​

Outputs​

Completion Standard​

Reading Policy​

Suggested Weekly Flow​

Reference​

Rich Learning Pages​