Requirements and System Architecture
Customer journeys, domain models, measurable requirements, API contracts, and system boundaries
User Journeys and Domain Modeling
Map signup, verification, organization creation, invitations, first value, upgrades, and cancellation before choosing libraries.
How to apply it
Model User, Organization, Membership, Project, Subscription, UsageEvent, and AuditEvent. A user can belong to multiple organizations, so Membership is a separate relationship. Write invariants such as every project belongs to one organization.
Worked example
A Membership record stores userId, organizationId, role, and status; each project stores organizationId and every access query is scoped to it.
Common mistakes to avoid
Putting all organization properties on User or leaving ownership rules implicit.
Practice task
Implement this concept in the capstone. Add one positive test, one negative or failure-path test, and a short note explaining the trade-off you chose.
- Map signup, verification, organization creation, invitations, first value, upgrades, and cancellation before choosing libraries.
- Model User, Organization, Membership, Project, Subscription, UsageEvent, and AuditEvent.
What is the strongest production practice for User Journeys and Domain Modeling?
Functional and Non-Functional Requirements
Functional requirements describe behavior; non-functional requirements define latency, availability, security, accessibility, and recovery.
How to apply it
Define measurable SLIs, SLOs, SLAs, RTO, and RPO. Document degraded behavior when dependencies fail, such as allowing existing work while upgrades wait for payment-provider recovery.
Worked example
Example: 95% of common reads under 300 ms at a specified load; critical service recovery within four hours.
Common mistakes to avoid
Using vague goals such as fast or confusing an internal target with a contractual SLA.
Practice task
Implement this concept in the capstone. Add one positive test, one negative or failure-path test, and a short note explaining the trade-off you chose.
- Functional requirements describe behavior; non-functional requirements define latency, availability, security, accessibility, and recovery.
- Define measurable SLIs, SLOs, SLAs, RTO, and RPO.
What is the strongest production practice for Functional and Non-Functional Requirements?
Architecture and API Design
A modular monolith is often a sensible starting point; microservices add operational and network complexity that needs justification.
How to apply it
Separate controllers, domain services, repositories, and integration adapters. Define validation, status codes, pagination, stable error shapes, request IDs, and idempotency for side-effecting requests.
Worked example
POST /api/v1/projects validates input, derives tenant context from authenticated server state, invokes a service, and returns 201. Errors include safe codes and request IDs, not stack traces.
Common mistakes to avoid
Starting with many microservices or trusting tenant IDs sent by the client.
Practice task
Implement this concept in the capstone. Add one positive test, one negative or failure-path test, and a short note explaining the trade-off you chose.
- A modular monolith is often a sensible starting point; microservices add operational and network complexity that needs justification.
- Separate controllers, domain services, repositories, and integration adapters.
What is the strongest production practice for Architecture and API Design?