Semester 7: Software Architecture & Domain Design
Year 3 -- Data & Architecture | Phase 7 | Weeks 70-75 | 6 weeks
Semester 7 is learner-facing across all five modules plus the semester project. The work here assumes you already understand systems, databases, and distributed tradeoffs well enough to make architecture decisions instead of collecting architecture vocabulary.
Goal
Turn prior systems knowledge into architecture work another engineer can inspect, challenge, and extend: boundaries, contracts, decision records, review packets, and explicit tradeoffs.
Prerequisites
Enter this semester after finishing the systems, operating-systems, networking, databases, and distributed-systems path. Architecture without those pressures quickly degrades into pattern memorization.
You should already be able to:
- reason about consistency, availability, latency, and recovery tradeoffs
- model a service or application boundary and explain what owns data
- write technical documents that another engineer can review
- connect code-level design decisions to operational consequences
Semester Structure
| # | Module | Status | Focus |
|---|---|---|---|
| 1 | Architecture Fundamentals & Quality Attributes | Learner-ready | Drivers, quality attributes, scenarios, tactics, tradeoffs |
| 2 | Architecture Patterns & Modular Monoliths | Learner-ready | Layered, pipeline, modular monolith, service-based, event-driven, microservices |
| 3 | Domain-Driven Design & Bounded Contexts | Learner-ready | Subdomains, context maps, aggregates, domain events, service alignment |
| 4 | API Design & Contract Evolution | Learner-ready | REST, RPC, GraphQL, compatibility, versioning, deprecation |
| 5 | Architecture Decision Records & Reviews | Learner-ready | ADRs, review methods, facilitation, fitness functions, drift |
Supporting semester artifacts:
- Project: architecture review packet for a realistic system
- Checkpoint: artifact-based readiness gate
- Cumulative Review: interleaved review across Semesters 0-7
- Exam: written architecture assessment under exam conditions
Why This Semester Exists
Earlier semesters teach how systems behave. This semester teaches how to shape them intentionally.
The semester is built to answer questions that show up in real engineering work:
- what architectural characteristics matter most for this system
- whether a modular monolith, services, or events are justified
- where bounded contexts should start and stop
- what an API contract promises and how it can evolve safely
- which decisions need ADRs, reviews, and executable checks
If you can describe a pattern but cannot defend why it belongs in a specific system, this semester is still incomplete.
Expected Deliverables
By the end of the semester you should have a reviewable packet of architecture artifacts, not just notes:
- quality-attribute scenarios tied to measurable system pressure
- one style-selection memo grounded in stated characteristics
- one domain model and context map for a realistic business problem
- one API contract fragment with compatibility and deprecation rules
- at least three ADRs with consequences and alternatives
- one lightweight architecture review packet with captured risks and follow-ups
- at least one fitness function or architecture-check concept you could automate in CI
Recommended Flow
Use the modules in order. Each later module assumes the earlier one is already internalized.
- Module 1: learn to identify architectural drivers and write measurable scenarios.
- Module 2: select architecture styles from those drivers instead of from trend pressure.
- Module 3: model the domain, bounded contexts, and transactional boundaries.
- Module 4: design contracts that match those boundaries and survive evolution.
- Module 5: record the important decisions, run reviews, and guard against drift.
- Project: combine the semester into one architecture review packet.
Semester Case
The recurring semester case is OrderFlow, a mid-size commerce order-fulfillment platform with checkout, payments, fulfillment, shipping, and support workflows.
It is large enough to force real architecture choices:
- external dependencies can fail
- multiple teams need boundaries
- APIs must evolve without constant breakage
- domain language differs across payment, shipping, support, and operations work
Use that case when you need a common system to test your reasoning against.
Completion Standard
Treat Semester 7 as complete only when you can do all of the following without hiding behind architecture buzzwords:
- name the top architectural characteristics of a system and defend them
- choose an architecture style by tradeoff, not by fashion
- draw a context map and explain every important edge
- design an API that exposes a clean contract and a credible evolution policy
- write an ADR that another engineer can challenge productively
- run a review that ends with a decision, risks, and follow-up actions in writing
If the artifacts would not survive peer review, the semester is not done.
Capstone Throughline
Every semester must leave behind evidence that can survive into the final capstone defense.
- Artifact carried forward: architecture packet and ADR set.
- What to preserve: Preserve context maps, quality-attribute scenarios, interface contracts, ADRs, and architecture review notes.
- Module threads: Module 1: Architecture Fundamentals & Quality Attributes, Module 2: Architecture Patterns & Modular Monoliths, Module 3: Domain-Driven Design & Bounded Contexts, Module 4: API Design & Contract Evolution, and Module 5: Architecture Decision Records & Reviews.
- Defense prompt: In Semester 10, explain how this semester's artifact changed a capstone decision, reduced a risk, or made the final system easier to defend.
Model Artifact Calibration
Use the ADR model artifact and the API evolution/deprecation policy model artifact to calibrate architecture and contract-governance deliverables.