Module 1: Domain Analysis & Architecture Design: Case Studies

These case studies are capstone framing rehearsals. Each one turns a vague project idea into a bounded, defensible, six-week architecture.

---

Case Study 1: Capstone Scope Too Large

Scenario: "Build a production-grade GitHub + Jira + Slack engineering intelligence platform" sounds impressive. In six weeks, it becomes a pile of half-built integrations.

Source anchor: The official C4 model keeps capstone architecture diagrams at context, container, and component level instead of drowning in implementation detail.

Module concepts: scope, MVP, vertical slice, risk register, C4.

Wrong Approach

Start with the full product vision.

Better Approach

Cut to one vertical slice:

User:
  engineering lead

Workflow:
  connect GitHub repo -> ingest PRs -> summarize review bottlenecks -> show dashboard

Out of scope:
  Jira, Slack, org-wide permissions, ML recommendations

Failure Mode

The team burns the schedule on breadth, reaches week six without a finished user path, and cannot defend architecture choices because the system never stabilizes.

Project / Capstone Connection

Apply this when choosing the single user journey your capstone must prove end to end before any expansion work.

Tradeoff Table

Option	Benefit	Cost	Better fit when
Broad multi-integration MVP	ambitious story	thin execution, high integration risk	you already have working adapters and prior code
One vertical slice	clear proof and demo path	less feature breadth	you need a defensible six-week capstone

Required Artifact

Write a capstone one-pager with problem, user, MVP slice, anti-scope, top three risks, and C4 context diagram.

---

Case Study 2: Architecture Characteristics Drive Style

Scenario: A learner chooses microservices because the capstone should look professional. The top drivers are delivery speed, simplicity, and demonstrable correctness.

Source anchor: Use SEI-style quality scenarios to rank architecture characteristics, then let those drivers decide whether a modular monolith, services split, or serverless layout is justified.

Module concepts: quality attributes, style choice, tradeoff, modular monolith.

Wrong Approach

Pick the style that sounds senior.

Better Approach

Choose by drivers:

Top drivers:
  delivery speed
  operability by one person
  clear domain boundaries

Style:
  modular monolith with explicit modules

Failure Mode

The project adopts infrastructure and coordination overhead that solves no real capstone problem and leaves less time for correctness, testing, and documentation.

Project / Capstone Connection

Use this when writing the ADR that explains why your capstone architecture matches its constraints instead of copying industry fashion.

Tradeoff Table

Option	Benefit	Cost	Better fit when
Microservices	isolated deployability	ops overhead, more moving parts	independent teams or scaling boundaries already exist
Modular monolith	fast delivery, simpler debugging	less independent deployability	one person owns the full capstone
Serverless-first	low ops surface	vendor coupling, workflow limits	event-driven workload is dominant

Required Artifact

Write a style ADR comparing modular monolith, services, and serverless for your capstone.

---

Case Study 3: EventStorming At Solo Scale

Scenario: A capstone domain has "users, projects, reports." The model feels generic until events reveal the real workflow.

Source anchor: EventStorming is useful here because event names expose the actual business flow, decision points, and boundaries that a noun list hides.

Module concepts: domain events, commands, policies, bounded context.

Wrong Approach

Model nouns first and stop.

Better Approach

Model events:

RepositoryConnected
PullRequestIngested
ReviewDelayDetected
ReportGenerated
ActionRecommended

Failure Mode

The domain model stays generic, bounded contexts blur together, and implementation devolves into CRUD with weak justification for the design.

Project / Capstone Connection

Use this to turn your capstone problem statement into a concrete event flow that can drive module boundaries and the first delivery slice.

Tradeoff Table

Option	Benefit	Cost	Better fit when
Noun-first modeling	fast to start	weak workflow insight	the domain is already well understood
Event-first modeling	sharper workflow and boundaries	takes more discovery effort upfront	the capstone domain still feels fuzzy

Required Artifact

Create a one-page event flow with commands, events, policies, read models, and candidate modules.

---

Case Study 4: ADRs Before Building

Scenario: The capstone starts coding immediately. By week four, database, deployment, and integration choices are implicit and hard to explain.

Source anchor: The ADR project gives a lightweight format for preserving context, decision, and consequence before implementation memory gets fuzzy.

Module concepts: ADR, decision memory, reversibility, consequence.

Wrong Approach

Document after the project is finished.

Better Approach

Write three ADRs before implementation:

ADR 1: architecture style
ADR 2: database and data model
ADR 3: deployment/runtime platform

Failure Mode

Important decisions become accidental, reviewers cannot tell whether tradeoffs were intentional, and later changes are harder because the original reasoning is missing.

Project / Capstone Connection

Use this to establish the three decisions your capstone defense will almost certainly be asked to justify.

Tradeoff Table

Option	Benefit	Cost	Better fit when
Implicit decisions	fastest short-term progress	weak explainability and harder reversals	the choice is trivial and low impact
ADR before build	decision clarity and audit trail	small documentation overhead	the choice affects architecture, data, or deployment

Required Artifact

Write three accepted ADRs with context, decision, consequences, and revisit trigger.

---

Case Study 5: Six-Week Plan Without Scope-Cut Rules

Scenario: The capstone plan fills every day with feature work. No time is reserved for deployment, security review, docs, or demo polish.

Source anchor: Risk-driven planning works only if the schedule names both mandatory proof points and the first things that get cut when reality intervenes.

Module concepts: schedule, scope cuts, risk, delivery planning.

Wrong Approach

Assume every planned feature lands.

Better Approach

Plan cuts:

Must ship:
  ingest -> analyze -> dashboard -> deploy -> defense

Cut first:
  multi-provider support
  advanced charts
  team invites

Never cut:
  deployment
  tests
  README
  defense artifacts

Failure Mode

The project spends all available time on new work, then reaches the final stretch without deployment proof, docs, or a coherent demo.

Project / Capstone Connection

Use this to shape the weekly plan for your own capstone, especially the non-feature work that must be protected.

Tradeoff Table

Option	Benefit	Cost	Better fit when
Feature-max schedule	more ambition on paper	fragile delivery and no buffer	requirements are fixed by an external sponsor
Scope-cut schedule	higher chance of a finished capstone	fewer stretch features	you control scope and must prove end-to-end competence

Required Artifact

Write a six-week delivery plan with weekly proof, scope-cut rules, and demo checkpoint.

---

Source Map

Source	Use it for
C4 model	choosing context, container, and component diagrams for a right-sized capstone
Architectural Decision Records	structuring ADRs with context, decision, and consequences

---

Completion Standard

• One capstone one-pager is complete.
• C4 context/container/component diagrams exist.
• Three ADRs are accepted.
• Six-week scope-cut plan is written.