Semester 7 Checkpoint Gate
The checkpoint must verify that the World-Class Strand evidence exists, is reproducible, and has a written highest-risk gap.
Required Output Classification
| Required output | Classification | Public/private guidance |
|---|---|---|
| Closed-book prompts, self-assessment answers, and skills matrices | Practice artifact | Use for honest calibration; do not publish raw answers unless rewritten as a study guide. |
| Required evidence gate items, sign-off checklist, and readiness decision | Checkpoint evidence | Keep 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 runbooks | Checkpoint evidence | Store beside the checkpoint so the remediation trail is inspectable without making mistakes public. |
| Reviewer notes or mentor feedback that materially improve a project artifact | Portfolio candidate | Convert 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
- Gather your Semester 7 artifacts in one folder or repo branch.
- Answer the prompts closed-book first.
- Review your own work against the rubric table.
- Fix the weakest module area before moving on to the exam.
Time box: 90-120 minutes.
Required Evidence
Bring concrete evidence for each module:
| Module | Minimum evidence |
|---|---|
| Module 1 | Top-three architectural characteristics plus at least 4 measurable quality scenarios |
| Module 2 | One style-selection memo and one module-boundary or topology sketch |
| Module 3 | One context map and one aggregate design with explicit invariants |
| Module 4 | One API contract fragment plus one compatibility or deprecation decision |
| Module 5 | At 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
- For a commerce platform, name the top three architectural characteristics you would optimize for first and explain why each outranks the others.
- Rewrite the vague requirement "checkout must be reliable and fast" as two measurable quality-attribute scenarios.
- Name one architecture move that improves deployability while worsening another characteristic, and state the tradeoff explicitly.
Module 2: Architecture Patterns & Modular Design
- When is a modular monolith the stronger default than microservices? Give two signals for it and two signals against it.
- Compare service-based architecture and microservices on deployment, data ownership, and operational cost.
- 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
- Explain the difference between a business domain, a subdomain, and a bounded context using one example.
- Draw or describe a context map edge that needs an anticorruption layer, and explain why conformist would be the wrong choice.
- Describe one aggregate you designed, its invariant, and why that invariant belongs inside one transactional boundary.
Module 4: API Design & Contract Evolution
- Classify three API changes as additive, breaking, or ambiguous, and justify each classification.
- When should you choose a custom action or long-running operation instead of forcing CRUD?
- Pick REST, gRPC, GraphQL, or event-driven for one cross-team integration and defend the choice in operational terms.
Module 5: ADRs & Architecture Reviews
- What makes a decision architectural rather than merely local design?
- Write the context, decision, and consequences for one real ADR in no more than 10 lines each.
- Describe the difference between a lightweight peer review and a heavier risk-driven review, and state when each is appropriate.
Artifact Review Rubric
| Area | Strong | Borderline | Failing |
|---|---|---|---|
| Quality scenarios | Measurable, prioritized, and tied to system pressure | Some specificity, but priorities or measures are weak | Buzzwords only |
| Style selection | Alternatives and tradeoffs are explicit | Choice is stated but lightly defended | Style chosen by preference or trend |
| Domain boundaries | Contexts, language, and invariants are coherent | Mostly plausible, but some boundaries leak | Contexts are arbitrary or CRUD-shaped |
| API contract | Consumer promises and compatibility rules are clear | Contract exists but evolution rules are thin | Contract is implementation-shaped |
| ADR and review quality | Decisions, consequences, and risks are visible | ADR exists but review value is limited | Decisions 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
| 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:
Reconciled extension requirements
Require level 2 in every module and strand category, alongside the existing 80% threshold. Demonstrate actual source enforcement, conflict/retry handling and one negative plus positive authorization trace. Missing independent review remains incomplete. Follow the workload and progression contract and required security strand.
Assistance and verification evidence
Complete the linked review exercise as required subchecks of AR1/AR2/AR5, using 3–4 hours of the existing 8–12-hour review experiments. Reuse the existing packet; no extra semester hours or gate IDs are added. All original real-system and independent-review requirements remain.