Semester 7 Project

Required Output Classification

Required output	Classification	Public/private guidance
Runnable project implementation and repository structure	`Portfolio candidate`	Polish the public repo only after tests pass, secrets are removed, and setup steps work from a clean checkout.
README with setup, inspection, verification instructions, and known limitations	`Portfolio candidate`	Make this public-facing if the project is safe to share; keep internal coursework notes in a private evidence folder.
Tests, traces, proofs, diagrams, benchmark outputs, or review notes required by the brief	`Checkpoint evidence`	Keep raw logs, benchmark runs, and reviewer comments private by default; publish summarized or reproducible versions when useful.
ADRs, design memos, runbooks, benchmark reports, and other high-effort engineering writeups	`Portfolio candidate`	These are worth polishing publicly when they tell a clear tradeoff story; otherwise keep them as private coursework evidence.
Final reflection, retrospective, or carry-forward notes	`Checkpoint evidence`	Keep candid self-assessment private unless rewritten as a concise public learning note.

Build an architecture review packet for OrderFlow, a mid-size commerce order-fulfillment platform. The deliverable should read like something you could hand to a senior engineer for critique.

Objective

Turn architecture terminology into reviewable work. This project is not asking for a giant implementation. It is asking for:

system context
drivers and quality scenarios
candidate views
a domain model and context map
a small API contract
a short ADR set
explicit risks and compatibility rules

System Context

OrderFlow handles the path from customer checkout to warehouse fulfillment and shipment tracking.

Primary actors:

customer
support agent
warehouse operator
payment provider
shipment carrier

Scope Assumptions

order volume spikes during promotions
carrier APIs are outside your control
support staff need near-real-time order state
the engineering team is large enough to need boundaries but not large enough to justify service sprawl everywhere

Drivers And Top Quality Attributes

Driver	Quality Attributes	Concrete Scenario
Promotions create sharp traffic spikes	Performance, availability	95 percent of checkout requests complete in under 300 ms during 2,000 concurrent checkout sessions
Carrier API outages are common	Availability, resilience	Orders continue to be accepted during a 10-minute carrier outage and shipment requests are retried later
Support needs fast order-state visibility	Operability, usability	Support can find the current order state and last transition in under 10 seconds
Multiple payment providers may be added	Modifiability	A new provider is added without changing warehouse-picking logic
Payment data is sensitive	Security	Payment tokens never appear in support APIs, logs, or warehouse workflows

Recommended Views

1. Logical / Modular View

checkout
orders
payments
fulfillment
shipping
support-read-model
shared platform services such as auth, jobs, and notification plumbing

2. Runtime / Communication View

synchronous checkout request for order creation and payment authorization
asynchronous job or event flow for shipment creation and notifications
read-model refresh for support-facing order status

3. Deployment View

one deployable application as a modular monolith
background worker process for jobs
relational database for core transactional state
queue or outbox-backed async integration with carrier and notification systems

Risks And Open Questions

Will the support read model drift too far behind the transactional state during peak load?
How will duplicate shipment requests be prevented during retries?
At what growth point would independently deployed services become worth the operational cost?
Which workflows require strict transactional consistency and which can tolerate eventual consistency?
What metrics will prove the architecture is meeting its claims?

Domain Model And Context Map

Core Terms

Term	Definition	Context
Cart	Customer-selected items before order submission	Checkout
Order	Confirmed purchase with status transitions	Order Management
Authorization	Payment approval attempt for an order	Payments
Pick List	Warehouse work instruction for selected inventory	Fulfillment
Shipment Request	Request to create a carrier shipment	Shipping
Order Timeline	Support-friendly view of order state transitions	Support Read Model

Boundary Notes

Order Management owns the lifecycle of the order.
Payments owns provider-specific authorization and settlement logic.
Fulfillment owns picking and packing workflows.
Shipping owns carrier integration and shipment creation.
Support Read Model is optimized for lookup and diagnosis, not transactional writes.

API Contract Snippet

Use a narrow contract fragment that matches the architecture story.

openapi: 3.1.0
info:
  title: OrderFlow Orders API
  version: 1.0.0
paths:
  /orders:
    post:
      summary: Submit a new order
      operationId: createOrder
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [customerId, items, paymentMethod]
              properties:
                customerId:
                  type: string
                items:
                  type: array
                  items:
                    type: object
                    required: [sku, quantity]
                    properties:
                      sku:
                        type: string
                      quantity:
                        type: integer
                        minimum: 1
                paymentMethod:
                  type: object
                  required: [provider, token]
                  properties:
                    provider:
                      type: string
                    token:
                      type: string
      responses:
        '202':
          description: Order accepted for processing
        '400':
          description: Invalid order payload
        '409':
          description: Duplicate or conflicting submission

Compatibility Rules

Additive response fields are allowed.
Existing field meanings may not change silently.
Breaking request changes require a new versioned contract.
Internal module refactors must not leak new payment-provider details into support or fulfillment APIs.
Idempotency expectations must be explicit for order submission and shipment creation.

ADR Set

Minimum ADRs:

ADR ID	Title	Status	Decision Summary
ADR-001	Use modular monolith as the initial deployment unit	Accepted	Optimize for simpler operations while enforcing strong internal boundaries
ADR-002	Use asynchronous shipment creation via queue or outbox	Accepted	Prevent carrier outages from blocking order intake
ADR-003	Introduce support-focused read model	Accepted	Optimize support workflows without exposing payment internals
ADR-004	Keep payment-provider logic isolated behind payments module interface	Accepted	Improve modifiability and reduce cross-module leakage

For each ADR, include:

context
decision
alternatives considered
consequences

Deliverables Checklist

Rubric

Criterion	Strong	Acceptable	Weak
Drivers and scenarios	Clear, measurable, and tied to real system pressure	Mostly clear, some vague wording remains	Buzzwords with little measurable content
Architecture choice	Tradeoffs explicit and justified against drivers	Choice stated with partial reasoning	Choice reads like pattern preference or trend following
Boundaries and domain model	Contexts, responsibilities, and language align cleanly	Boundaries mostly plausible with minor leaks	Boundaries are arbitrary or inconsistent
API and compatibility	Contract matches architecture story and evolution rules are credible	Contract exists but compatibility rules are thin	Contract is disconnected from the rest of the design
Risks and ADRs	Risks are honest and ADRs show real alternatives	Some risks and decisions documented	Risks hidden and ADRs feel ceremonial
Practical value	Another engineer could review and challenge the packet meaningfully	Packet is usable but incomplete in parts	Packet reads like theory notes, not engineering work

Added Case Option

You may use a restaurant-management system as the semester case instead of the default commerce case.

Required scope:

reservation and table assignment
order and kitchen status
payment closure
manager reporting
role-specific language for host, server, kitchen, manager, and guest

Required evidence:

requirements analysis with at least 12 domain terms
bounded-context map and aggregate list
style-selection memo
three ADRs with risks, alternatives, consequences, and follow-up decisions
review packet that names the top five risks and which artifact addresses each risk

Production-Style Project Brief

Use this project as a reviewable engineering brief, not only a completion exercise.

Problem statement

Write a one-paragraph statement covering the user, the problem, the constraint, and the outcome this project is meant to produce.

Required evidence

working artifact or reproducible deliverable
README with setup, inspection, and verification instructions
tests, traces, proofs, diagrams, benchmark output, or review notes appropriate to the semester
decision log with at least three meaningful tradeoffs
known limitations section with explicit scope cuts

Review questions

What is the smallest vertical slice that proves the project works?
Which requirement is most likely to be misunderstood by a reviewer?
What did you deliberately not build, and why?
What evidence would convince someone else that the result is correct?

Done means

The project is done only when another technical reader can inspect the artifact, run or review the verification evidence, and understand the tradeoffs without a live explanation.

Weekly Project Milestones

Use these milestones to keep the project from becoming a last-week scramble.

Milestone	Focus	Evidence
Start	Scope the smallest useful slice	problem statement, non-goals, first task list
Early build	Produce a walking version	runnable skeleton, first test, first committed artifact
Middle	Add the hard part	implementation note, trace/proof/benchmark/design decision
Review	Stress the weak point	failure case, debugging note, peer/self review, correction commit
Finish	Package for inspection	README, verification instructions, known limitations, reflection

Answer-Quality Examples

Quality	What it sounds like
Weak	"I built it because the module asked for it."
Acceptable	"It works for the required examples and I can explain the main idea."
Strong	"Here is the tradeoff I chose, the evidence that supports it, and the case where it would fail."
Portfolio-ready	"A reviewer can inspect the artifact, rerun the checks, and understand why this solution fits this semester's goals."

Future Capstone Connection

Before closing this project, write two sentences on how it could help the final capstone: one reusable technical skill and one artifact habit to preserve.

Calibration Materials

Use these learner-visible calibration materials before self-grading or requesting review:

Required Output Classification​

Objective​

System Context​

Scope Assumptions​

Drivers And Top Quality Attributes​

Recommended Views​

1. Logical / Modular View​

2. Runtime / Communication View​

3. Deployment View​

Risks And Open Questions​

Domain Model And Context Map​

Core Terms​

Boundary Notes​

API Contract Snippet​

Compatibility Rules​

ADR Set​

Deliverables Checklist​

Rubric​

Added Case Option​

Production-Style Project Brief​

Problem statement​

Required evidence​

Review questions​

Done means​

Weekly Project Milestones​

Answer-Quality Examples​

Future Capstone Connection​

Before closing this project, write two sentences on how it could help the final capstone: one reusable technical skill and one artifact habit to preserve.​

Calibration Materials​