Designing a Production-Ready Full-Stack App
Define boundaries between UI, API, domain logic, and persistence.
Learning objectives
By the end of this lesson, you should be able to:
- Explain the key concepts and when they are useful.
- Apply the concepts to a realistic engineering scenario.
- Identify common failure modes and choose a practical mitigation.
- Complete the assignment and explain your design decisions.
Core concepts
A production application is more than a React screen connected to an endpoint. Separate presentation, application orchestration, domain rules, and infrastructure so each layer can be tested independently. Keep business invariants out of UI components and avoid making controllers responsible for database workflows.
Worked example
Use a request path such as Browser → Route/Controller → Application Service → Repository → Database. The response travels back through a DTO rather than exposing a persistence entity. Document ownership of validation, authorization, and error mapping for every layer.
Engineering principles
- Make assumptions explicit. Document expected inputs, outputs, ownership, and failure behavior.
- Validate at boundaries. Treat user input, files, messages, and third-party responses as untrusted.
- Design for failure. Decide what happens when dependencies time out, data is malformed, or a process is retried.
- Prefer observable behavior. Log meaningful outcomes and expose enough diagnostics to debug without leaking secrets.
- Test the invariant. A test should prove a property that must remain true, not merely repeat the implementation.
Practical assignment
Design a small issue tracker. Draw its request flow and list which layer owns input validation, permission checks, status transitions, persistence, and response formatting.
Suggested solution and reasoning
A reasonable split is: UI validates interaction state; API validates untrusted input; service enforces rules such as valid status transitions; repository persists; controller maps domain results to HTTP responses. Security checks belong server-side even if the UI hides unavailable actions.
Use this as a reference design, not the only possible answer. A strong submission states assumptions, includes failure cases, and demonstrates how correctness will be tested.
Knowledge check
- What problem does this design solve, and what simpler alternative did you consider?
- Which input or dependency is most likely to fail?
- What invariant must remain true after a retry?
- How would you test the unhappy path?
Completion checklist
- I can explain the concepts without reading the lesson.
- I completed the practical assignment.
- I tested at least one failure scenario.
- I documented trade-offs and next steps.