Skip to main content

Architecture Choice Clinic

A 90-minute clinic where you turn your domain model into an architectural decision with evidence. You leave with a characteristics list, a style decision, and at least one running fitness function.

Retrieval Prompts​

  1. Why do we pick top-3 characteristics instead of all characteristics?
  2. State the three architectural styles realistic for a capstone.
  3. What does a fitness function have that a unit test does not?
  4. Where does the top-3 characteristics list live in the design doc?
  5. Why must a non-goal characteristic be written down explicitly?

Compare and Distinguish​

  • driver versus supported versus non-goal characteristic
  • monolith versus modular monolith versus services
  • fitness function versus unit test versus integration test
  • architectural style decision versus framework decision
  • "scaled" versus "scalable"

Common Mistake Check​

Identify the error:

  1. "All 10 characteristics are drivers for my capstone."
  2. "I'm using microservices because it's the modern choice."
  3. "I'll add fitness functions after the code is working."
  4. "Availability is always a top-3 characteristic."
  5. "My fitness function tests one function for correctness."

Mini Application: Three Artifacts​

Artifact 1 -- Characteristics ranking​

From a list of 10-15 candidate characteristics, filter (using the "would the user notice?" test), rank, and split into three columns: Drivers (top 3), Supported, Non-goals. For each driver, write the design implication in one sentence.

Commit to library/raw/architecture/characteristics.md.

Artifact 2 -- Style decision with three alternatives​

Write the three-alternatives passage from concept 08. Present monolith, modular monolith, and services as alternatives with honest pro/con vs your top-3 characteristics. Pick one. Paragraph-justify the pick.

This passage goes into the design doc's Architecture section and becomes the core of ADR-001.

Commit updated library/raw/design-doc.md.

Artifact 3 -- One fitness function, running​

Pick one top-3 characteristic. Translate it into the smallest possible check:

  • A module-boundary test (if simplicity / modularity is your driver).
  • A latency assertion on a load-test harness (if performance is a driver).
  • A CI deploy-time health check (if operability is a driver).

Write it. Commit it. Wire it into CI. Make it fail once (deliberately break the claim) to verify the signal. Then revert.

Commit to tests/arch/ or equivalent path. Reference from library/raw/architecture/fitness-functions.md.

Evidence Check​

  • Exactly three characteristics are marked drivers; at least two non-goals are written down.
  • The style decision names three alternatives and rejects two with a specific sentence per rejection.
  • The style decision justification cites at least one top-3 characteristic and at least one risk-register row.
  • At least one fitness function is committed to the repo and runs in CI.
  • The fitness function has been observed failing (deliberately), confirming the signal works.
  • You can name one design decision your characteristics forced, and one they prevented.