Reference Architecture Overview
Why this section matters
Reference architectures help architects move faster without pretending every product is identical. They give you a starting shape, the forces behind it, the risks to check, and the artifacts to produce.
How to use a reference architecture
Do not copy a blueprint blindly. Use it as a decision scaffold:
- Confirm the product forces.
- Adjust the quality model.
- Identify the risky boundaries.
- Write the ADRs that differ from the reference.
- Create route, data, security, and performance review artifacts.
Blueprint map
Common architecture layers
| Layer | What the blueprint should define |
|---|---|
| route model | public/private routes, shells, rendering mode, cacheability |
| data model | source of truth, BFF/API boundaries, caches, invalidation |
| state model | URL, server, local UI, global shell, offline queue |
| quality model | performance, accessibility, reliability, security, privacy |
| delivery model | flags, releases, rollback, migration, observability |
| ownership model | product owner, platform owner, operational owner |
Review checklist
- Is the selected reference architecture driven by product forces?
- Are deviations from the blueprint documented?
- Are quality gates proportional to the surface risk?
- Are route, data, security, and observability artifacts created?
Exercises
- Pick one product you know and match it to the closest blueprint.
- List three ways the blueprint would need to change for your context.
- Write one ADR for a deliberate deviation.
Source lens
These blueprints connect Part 0 foundations, Part III rendering/data, Part IV modularity, Part VI performance, Part VIII reliability/security, and the capstones.