Semester 7 Exam
Required Output Classification
| Required output | Classification | Public/private guidance |
|---|---|---|
| Timed written answers, diagrams, code snippets, and design responses | Checkpoint evidence | Keep raw exam work private so it remains useful for assessment and retake calibration. |
| Post-exam review notes, missed-answer repairs, and Feynman explanations | Practice artifact | Use for spaced review; publish only rewritten explanations that no longer reveal exam solutions wholesale. |
| Capstone-defense or architecture-defense packets created from exam prompts | Portfolio candidate | Polish publicly only when they are original to your project, sanitized, and framed as engineering rationale rather than exam answers. |
This exam checks whether you can turn architecture concepts into clear engineering judgments and reviewable artifacts.
Rules
- Duration: 3 hours
- Format: closed book for Sections A-E, open notes for Section F only if you are evaluating your own existing artifact
- Deliverable style: concise written answers, diagrams, short tables, and one ADR-quality decision writeup
- Passing bar: strong answers in every section; one excellent section does not offset a weak boundary, API, or ADR section
Section A: Architecture Fundamentals & Quality Attributes
- A team is building an internal payments-routing platform used by three product lines. List the top three architectural characteristics you would optimize for in the first release, and justify the ranking.
- Rewrite these vague requirements as measurable quality-attribute scenarios:
- "The platform should be reliable."
- "The platform should be easy to change."
- A proposal improves independent deployability but adds cross-service latency, duplicate failure modes, and more operational overhead. Explain the tradeoff and state when you would still accept it.
Section B: Architecture Patterns & Modular Design
- Compare these four options for a new commerce platform: layered monolith, modular monolith, service-based architecture, microservices. For each, name the strongest fit condition and the primary failure mode.
- The current application is one deployable unit but has tangled package boundaries, shared utility code everywhere, and team-level ownership fights. Explain why "still one deployment unit" does not automatically mean "modular monolith."
- Write two architecture-boundary checks you would enforce in CI for a modular monolith, and state the violation each check is meant to catch.
Section C: Domain-Driven Design & Bounded Contexts
- For a parcel-shipping business, propose four bounded contexts and classify each related subdomain as core, supporting, or generic.
- Pick one edge between two of those contexts and choose the relationship pattern you would apply: partnership, customer-supplier, conformist, anticorruption layer, open host service, or published language. Defend the choice.
- Design one aggregate inside one of those contexts. Name:
- the aggregate root
- one invariant
- one value object
- one event the aggregate emits
- one thing you deliberately refuse to update in the same transaction
Section D: API Design & Contract Evolution
- Design a small external-facing HTTP API for shipment tracking. Include:
- core resources
- verbs and status codes
- pagination approach
- one custom action or long-running operation if needed
- Classify each change below as backward-compatible, forward-compatible, or breaking, and justify the answer:
- add an optional field to a response
- rename a response field
- change sort order without warning
- add a new enum value to a request field
- For an internal integration between pricing and checkout, choose one style: REST, gRPC, GraphQL, or event-driven. Defend the choice against at least one alternative.
Section E: ADRs & Architecture Reviews
- Write a compact ADR for the decision "Use a modular monolith as the initial deployment unit." Include context, decision, alternatives considered, and consequences.
- A teammate proposes introducing microservices for "better scalability." Describe how you would review that proposal. State:
- which review method you would use
- which stakeholders you would involve
- which risks or evidence you would ask for before deciding
- Name one architectural claim from this semester that can become a fitness function and one that cannot yet be automated. Explain why.
Section F: Integrated Architecture Packet
Use the semester case or your own equivalent system.
- Produce a one-page architecture review summary containing all of the following:
- system purpose
- top three architectural characteristics
- chosen style and rejected alternative
- proposed bounded contexts
- one API surface that must remain stable
- one ADR title
- top two risks
- Add a short reviewer note naming the weakest assumption in your own design and how you would validate it.
This section is where weak abstractions usually get exposed. If the system story, boundaries, and contract do not align, the answer is incomplete.
Scoring Rubric
| Section | Max | What earns full marks |
|---|---|---|
| A | 20 | Prioritized characteristics, measurable scenarios, explicit tradeoffs |
| B | 15 | Correct style comparisons and enforceable modular-boundary reasoning |
| C | 20 | Credible bounded contexts, correct relationship pattern, disciplined aggregate design |
| D | 20 | Coherent API contract, accurate compatibility reasoning, justified integration-style choice |
| E | 15 | ADR quality, appropriate review method, realistic fitness-function thinking |
| F | 10 | Coherent end-to-end packet with aligned decisions and honest risk assessment |
Recommended pass threshold: 75/100, with no section below half credit.
What To Review If You Miss
- Weak Section A: revisit Module 1
- Weak Section B: revisit Module 2
- Weak Section C: revisit Module 3
- Weak Section D: revisit Module 4
- Weak Section E: revisit Module 5
- Weak Section F: revisit the Semester Project and rebuild the packet with tighter alignment
Mastery Rubric
| Level | Evidence |
|---|---|
| Beginner pass | Can answer direct questions and complete familiar exercises with light notes. |
| Solid pass | Can solve new variants, explain choices, and connect the work to Semester 6 Databases and Distributed Systems. |
| Strong pass | Can defend tradeoffs, identify failure modes, and produce clean evidence in the portfolio artifact. |
| Not ready | Relies on copied solutions, cannot explain mistakes, or lacks durable artifacts. |
Retake and Repair Rule
If a section is weak, do not only reread. Repair it by producing new evidence: a corrected solution, a fresh implementation, a rewritten proof, a benchmark, a diagram, a runbook, or a short teaching note.
Answer-Quality Examples
Use these examples when grading written answers or spoken explanations.
| Quality | Example pattern |
|---|---|
| Weak | Names a concept but gives no example, constraint, or failure case. |
| Acceptable | Defines the concept and applies it to a familiar exercise. |
| Strong | Applies the concept to a new variant and explains why an alternative would fail. |
| Portfolio-ready | Connects the concept to Semester 6 Databases and Distributed Systems, current project evidence, and a future capstone decision. |
Interleaving Prompt
For any missed answer, add one sentence starting with: This depends on an earlier skill because...
Calibration Materials
Use these learner-visible calibration materials before self-grading or requesting review: