Skip to main content

Semester 7 Checkpoint Gate

Required Output Classification​

Required outputClassificationPublic/private guidance
Closed-book prompts, self-assessment answers, and skills matricesPractice artifactUse for honest calibration; do not publish raw answers unless rewritten as a study guide.
Required evidence gate items, sign-off checklist, and readiness decisionCheckpoint evidenceKeep as private progression evidence; share only sanitized summaries with mentors or reviewers.
Repair artifacts produced after a weak checkpoint, such as corrected solutions, diagrams, traces, benchmarks, or runbooksCheckpoint evidenceStore beside the checkpoint so the remediation trail is inspectable without making mistakes public.
Reviewer notes or mentor feedback that materially improve a project artifactPortfolio candidateConvert into public-safe acknowledgements or changelog entries only after removing private feedback context.

Use this gate after finishing the five modules and before treating the semester project as complete. The standard here is artifact quality, not recognition-memory familiarity.

How To Run The Checkpoint​

  1. Gather your Semester 7 artifacts in one folder or repo branch.
  2. Answer the prompts closed-book first.
  3. Review your own work against the rubric table.
  4. Fix the weakest module area before moving on to the exam.

Time box: 90-120 minutes.

Required Evidence​

Bring concrete evidence for each module:

ModuleMinimum evidence
Module 1Top-three architectural characteristics plus at least 4 measurable quality scenarios
Module 2One style-selection memo and one module-boundary or topology sketch
Module 3One context map and one aggregate design with explicit invariants
Module 4One API contract fragment plus one compatibility or deprecation decision
Module 5At least one ADR and one review output with captured risks or follow-ups

If any row is missing, the checkpoint is not passed.

Closed-Book Verification​

Answer these in writing without opening notes.

Module 1: Architecture Fundamentals & Quality Attributes​

  1. For a commerce platform, name the top three architectural characteristics you would optimize for first and explain why each outranks the others.
  2. Rewrite the vague requirement "checkout must be reliable and fast" as two measurable quality-attribute scenarios.
  3. Name one architecture move that improves deployability while worsening another characteristic, and state the tradeoff explicitly.

Module 2: Architecture Patterns & Modular Design​

  1. When is a modular monolith the stronger default than microservices? Give two signals for it and two signals against it.
  2. Compare service-based architecture and microservices on deployment, data ownership, and operational cost.
  3. Name one boundary rule you would enforce in CI for a modular monolith and the failure it is meant to catch.

Module 3: Domain-Driven Design & Bounded Contexts​

  1. Explain the difference between a business domain, a subdomain, and a bounded context using one example.
  2. Draw or describe a context map edge that needs an anticorruption layer, and explain why conformist would be the wrong choice.
  3. Describe one aggregate you designed, its invariant, and why that invariant belongs inside one transactional boundary.

Module 4: API Design & Contract Evolution​

  1. Classify three API changes as additive, breaking, or ambiguous, and justify each classification.
  2. When should you choose a custom action or long-running operation instead of forcing CRUD?
  3. Pick REST, gRPC, GraphQL, or event-driven for one cross-team integration and defend the choice in operational terms.

Module 5: ADRs & Architecture Reviews​

  1. What makes a decision architectural rather than merely local design?
  2. Write the context, decision, and consequences for one real ADR in no more than 10 lines each.
  3. Describe the difference between a lightweight peer review and a heavier risk-driven review, and state when each is appropriate.

Artifact Review Rubric​

AreaStrongBorderlineFailing
Quality scenariosMeasurable, prioritized, and tied to system pressureSome specificity, but priorities or measures are weakBuzzwords only
Style selectionAlternatives and tradeoffs are explicitChoice is stated but lightly defendedStyle chosen by preference or trend
Domain boundariesContexts, language, and invariants are coherentMostly plausible, but some boundaries leakContexts are arbitrary or CRUD-shaped
API contractConsumer promises and compatibility rules are clearContract exists but evolution rules are thinContract is implementation-shaped
ADR and review qualityDecisions, consequences, and risks are visibleADR exists but review value is limitedDecisions are undocumented or ceremonial

You should not advance if more than one row is borderline, or if any row is failing.

Common Failure Modes​

Watch for these before signing off:

  • architecture characteristics are listed but not prioritized
  • microservices are proposed without pricing the operational tax
  • bounded contexts are really team boundaries or table ownership
  • API versioning is used as a substitute for contract discipline
  • ADRs record the decision but not the consequences
  • architecture reviews end with opinions instead of written outcomes

Sign-Off​

  • Checkpoint date:
  • Modules that still need rework:
  • Weakest artifact in the semester:
  • Next fix before exam:

Added Gate Evidence​

Bring one review packet for the restaurant-management or equivalent case:

  • architecture style walkthrough from client action to persistence
  • context map and aggregate notes
  • ADR set with alternatives and consequences
  • risk list with owner, mitigation, and follow-up date
  • short note explaining what would change if the team doubled or load increased 10x

Mastery Rubric​

LevelEvidence
Beginner passCan answer direct questions and complete familiar exercises with light notes.
Solid passCan solve new variants, explain choices, and connect the work to Semester 6 Databases and Distributed Systems.
Strong passCan defend tradeoffs, identify failure modes, and produce clean evidence in the portfolio artifact.
Not readyRelies 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.

QualityExample pattern
WeakNames a concept but gives no example, constraint, or failure case.
AcceptableDefines the concept and applies it to a familiar exercise.
StrongApplies the concept to a new variant and explains why an alternative would fail.
Portfolio-readyConnects 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: