Module 1: Domain Analysis & Architecture Design

Primary text(s): No new required book. Revisit prior-semester guides as reference. Selective support: S7 M01 Architecture Fundamentals, S7 M03 Domain-Driven Design, S7 M05 ADRs & Reviews, S8 M01 System Design Methodology, S6 M05 Distributed Systems Fundamentals. Firecrawl-validated sources listed in resources.md -- opened only when a specific cluster question cannot be answered from memory.

This module does not teach architecture from scratch. You have already learned it. The module's job is to turn that learning into a single, written, defensible architecture for one real capstone project -- your capstone -- and to do it in the first week of the 6-week capstone window.

Scope of This Module

This module is the framing phase of the capstone. It is deliberately short, deliberately writing-heavy, and deliberately terminal: what you decide here is what you will be delivering, testing, deploying, and defending over the next five weeks.

What it covers in depth:

choosing a capstone problem that is right-sized, motivated, and defensible
identifying the scariest unknowns first (risk register) and letting those drive the architecture
defining the MVP as the vertical slice that proves the system end-to-end
applying EventStorming (or Domain Message Flow) at solo-project scale without drowning in sticky notes
separating core, supporting, and generic subdomains so effort lands where it must
holding a ubiquitous language with yourself (solo-team language discipline)
selecting the top-3 architecture characteristics that drive the system
choosing a style (monolith, modular monolith, services) that matches those characteristics and the 6-week budget
writing fitness functions that will keep the architecture honest as you build
writing a single capstone design doc that replaces 5 smaller documents
drawing C4 at Context, Container, and Component levels -- and no further
writing three must-write ADRs for the capstone
planning a realistic 6-week schedule that anticipates slippage
setting scope-cut rules before you need them
preparing the 5-minute defense of the architecture, in advance

What it deliberately does not try to finish here:

implementation (that is Module 2)
CI/CD and deployment wiring (Module 3)
operational readiness and security review (Module 4)
portfolio packaging (Module 5)

This is the integrative capstone framing module. Everything in it is about one project, yours, this week.

Before You Start

Answer these closed-book before starting the main path:

Give one example of a problem that is too large for a 6-week solo capstone, and explain why.
What does a bounded context give you that a "module" does not?
What are the three required sections of an ADR and what fails when any is missing?
Name an architecture characteristic (e.g., availability, scalability, security, operability) that is a driver versus a non-goal for your capstone idea.
What is the difference between an MVP and a prototype?

Diagnostic Interpretation

4-5 solid answers

You are ready. Go straight to Cluster 1.

2-3 solid answers

Continue, but revisit S7 M03 (DDD) for Cluster 2 and S7 M05 (ADRs) for Cluster 4 while you work.

0-1 solid answers

Stop. Review S7 M01 (Architecture Fundamentals) and S8 M01 (System Design Methodology). This module assumes those are already in your fingertips.

What This Module Is For

Capstones fail for predictable reasons: they are too big, they have no written decisions, they have no vertical slice until week 5, they answer the wrong question, or they cannot be defended in five minutes without slides. This module is the antidote to all of those.

By the end of this week you will have:

a one-paragraph problem statement that you can defend against "why this?"
a 3-row risk register where the top risk is the thing you are most afraid of
an MVP defined as a single vertical slice the grader could run
a domain model with core/supporting/generic subdomains identified
a chosen architectural style with three characteristics driving it
at least one fitness function that you will actually run in CI
a capstone design doc, three ADRs, and a C4 diagram set (Context, Container, Component)
a 6-week plan with explicit scope-cut rules
a rehearsed answer to "what if someone asked you X?"

This is where engineering judgment becomes visible. If the module is done well, Module 2 becomes easier; if it is skipped, every later module gets harder.

Concept Map

How To Use This Module

Work in order. Cluster 1 gates Cluster 2; Cluster 2 gates Cluster 3; and nothing in Cluster 4 is real until Clusters 1-3 are done. Finish the whole module in week 1 of the capstone. Move to Module 2 in week 2 even if this module is "90% done" -- shipping beats polishing.

Cluster 1: Scoping a Capstone

Order	Concept	Type	Focus
1	Problem Selection: Right-Sized, Motivated, Defensible	PRIMARY	How to pick a capstone problem you can finish and defend
2	Risk Register: The Scariest Unknowns First	PRIMARY	Naming the top risks so they drive architecture, not the other way around
3	MVP Definition: The Vertical Slice That Proves the System	PRIMARY	MVP as an end-to-end happy path, not a sprint backlog

Cluster mastery check: Can you say your capstone in one paragraph, list its top 3 risks, and describe the single slice that would prove it end-to-end?

Cluster 2: Domain Discovery

Order	Concept	Type	Focus
4	EventStorming at Capstone Scale	PRIMARY	Big-picture and process-level EventStorming when the team is one
5	Core vs Supporting vs Generic Subdomains	PRIMARY	Where your energy must go vs where "good enough" ships
6	Ubiquitous Language for a Team of One	PRIMARY	Why solo language discipline still matters, and how to enforce it

Cluster mastery check: Can you point to the one subdomain that is your capstone's reason to exist, and justify why the others are supporting or generic?

Cluster 3: Architecture Decision

Order	Concept	Type	Focus
7	Characteristics Selection: Top-3 Drivers	PRIMARY	Picking the 3 non-functional concerns that drive the architecture
8	Style Selection: Monolith, Modular Monolith, Services	PRIMARY	The honest tradeoff given your characteristics and 6-week budget
9	Fitness Functions That Keep the Architecture Honest	PRIMARY	Turning architectural claims into CI checks

Cluster mastery check: Given your top-3 characteristics, can you defend the chosen style in a paragraph and name one fitness function per characteristic that you will actually run?

Cluster 4: Design Communication

Order	Concept	Type	Focus
10	The Capstone Design Doc: Structure, Length, Audience	PRIMARY	One doc, 4-8 pages, for the grader and for you in week 5
11	C4 Diagrams at Three Levels	PRIMARY	Context, Container, Component -- and why Level 4 is rarely needed
12	ADRs for the Capstone: Three Must-Write Decisions	PRIMARY	The three decisions you will be asked about, written down once

Cluster mastery check: Can you hand someone the design doc + three diagrams + three ADRs and have them explain your system back to you correctly?

Cluster 5: Planning for Reality

Order	Concept	Type	Focus
13	A 6-Week Capstone Schedule: Anti-Patterns and Recovery Moves	PRIMARY	Week-by-week plan with failure modes already anticipated
14	Scope Control: Cut Rules Before You Need Them	PRIMARY	Writing the scope-cut list while you're still optimistic
15	Defense: What Will Someone Ask, and What Is Your Answer	SUPPORTING	Rehearsing the 5-minute architecture defense in week 1

Cluster mastery check: Can you show your week-by-week plan, your scope-cut list, and give a 5-minute architecture defense from memory, today?

Then work these practice pages:

Order	Practice path	Focus
1	Capstone Scoping Lab	Problem statement, risk register, MVP -- written for your real project
2	Domain Discovery Workshop	EventStorming (or Domain Message Flow) for your capstone
3	Architecture Choice Clinic	Characteristics list, style decision, fitness functions
4	Design Doc and ADR Katas	Write the design doc, draw C4, author three ADRs, rehearse defense

Use Module Quiz after the concept and practice path. Use Reference and Cross-Semester Map and Learning Resources only for targeted reinforcement.

Learning Objectives

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

State your capstone problem in one paragraph and defend why it is the right size, the right motivation, and defensible against grader critique.
Produce a risk register where the top-3 rows are the scariest unknowns, each with a mitigation and an architecture implication.
Define the MVP as a single vertical slice that exercises every layer of the system.
Run an EventStorming (or Domain Message Flow) session on yourself and end with a labeled domain model.
Classify your subdomains as core, supporting, or generic, and allocate your 6-week effort accordingly.
Maintain a short glossary of terms -- the ubiquitous language -- and enforce it in code, tests, and diagrams.
Pick the top-3 architecture characteristics, rank them, and explain what you are choosing against.
Select a style (monolith / modular monolith / services), in writing, with an honest justification tied to your characteristics and budget.
Write at least one executable fitness function per top-characteristic and have it running before Module 2.
Produce one capstone design doc, one C4 diagram set, and three ADRs that together let another engineer defend the architecture in your absence.
Build a 6-week schedule with scope-cut rules written in advance.
Deliver a 5-minute architecture defense from memory.

Outputs

one problem statement paragraph and one "why this?" memo, both written by the end of day 1
one risk register with at least 5 rows, top 3 marked as architecturally-significant
one MVP definition: user, trigger, happy-path steps, success condition, explicit non-goals
one EventStorming (or Domain Message Flow) artifact with at least 12 events
one subdomain map labeling core, supporting, and generic
one glossary of at least 10 ubiquitous-language terms
one characteristics ranking sheet with top 3 marked, non-goals marked
one written style decision with three alternatives considered
at least two fitness functions committed to the capstone repo
one design doc (4-8 pages)
one C4 diagram set (Context, Container, Component)
three ADRs (datastore, primary technology choice, deployment topology)
one 6-week schedule with written scope-cut rules
one rehearsed 5-minute architecture defense (recorded or notes)

Completion Standard

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

you can describe the capstone in one paragraph without looking at notes
you can name the top 3 risks and the architecture implication of each
you can point to the one vertical slice that proves the system
you can show the core subdomain and justify the others as supporting or generic
you have three ADRs written, each with context, decision, consequences
you have a C4 diagram set, including a Component diagram for at least the core subdomain
you have at least one fitness function failing-then-passing in your capstone repo
you have a 6-week plan and a list of pre-committed scope cuts
you can give the 5-minute defense from memory

If you have diagrams but cannot explain a single trade-off in words, this module is not complete.

Reading Policy

Concept pages are the main path.
Prior-semester modules (S7 M01, S7 M03, S7 M05, S8 M01, S6 M05) are escalation, not syllabus. Revisit a single concept page there, not the whole module.
External URLs listed in resources.md are validated and targeted. Open one per concept gap.
See also (integrative) replaces Read This Only If Stuck in this module -- the assumption is you already learned the concept and now need to apply it.

Suggested Weekly Flow (Week 1 of the Capstone)

Day	Work
1 (Mon)	Concepts 1-3 and a full Capstone Scoping Lab (Practice 1)
2 (Tue)	Concepts 4-6 and a Domain Discovery Workshop (Practice 2)
3 (Wed)	Concepts 7-9 and the Architecture Choice Clinic (Practice 3)
4 (Thu)	Concepts 10-12 and the Design Doc + ADR Katas (Practice 4 part 1)
5 (Fri)	Concepts 13-15, C4 diagrams, and the 5-minute defense (Practice 4 part 2)
6 (Sat)	Quiz, clean up design doc, commit first fitness function
7 (Sun)	Rest, then read through your own design doc cold and mark anything unclear

Reference

For cross-semester concept recovery and external source maps, use Reference and Cross-Semester Map.

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: Scoping a Capstone​

Cluster 2: Domain Discovery​

Cluster 3: Architecture Decision​

Cluster 4: Design Communication​

Cluster 5: Planning for Reality​

Learning Objectives​

Outputs​

Completion Standard​

Reading Policy​

Suggested Weekly Flow (Week 1 of the Capstone)​

Reference​

Rich Learning Pages​