Architecture patterns — Mission
Sections
Reading settings
No voice for this language in this browser.
More voices
Code and English terms
Off: the page’s voice reads everything, with no pause between two voices.
No voice for this language in this browser.
More voices
More voices: Microsoft Edge has natural online voices, and Windows (Settings › Time & language › Speech), macOS and Android install others.
Mission
Section titled “Mission”Choose a boundary because it makes a specific change safer or cheaper. This course compares five architectural patterns without treating them as a ranking. It complements the hexagonal architecture course by asking when a simpler layered design is sufficient, how onion and clean architecture overlap with ports and adapters, and why a modular monolith addresses a different decision.
Our tracer use case is save a guitarist’s practice plan: accept a named plan containing three chord shapes, validate it against a catalog revision, persist it, and return a receipt. All four lessons use this same case. It is a teaching design, not a feature implemented in any ecosystem repository.
Prerequisites and completion
Section titled “Prerequisites and completion”Know functions, interfaces, a database transaction and the difference between a process and a library. No account, paid model or service is required. The exercises are design and failure-trace exercises with worked solutions; there is no executable application or performance benchmark in this first slice.
You finish with a dependency map, a contract, a failure table and a one-page decision whose rejection conditions another developer can test. Suggested time: two hours; this is a study estimate, not a measured completion time.
| Lesson | Deliverable |
|---|---|
| 1. Start with a change | Assumptions, invariants and a measurable baseline |
| 2. Five patterns, one use case | Dependency and ownership comparison |
| 3. When a boundary crosses a process | Retry, concurrency and recovery contract |
| 4. Evaluate an ecosystem seam | Bounded GA/Gaia/IX/Demerzel experiment and decision |
| Journal | Sources, validation evidence and unverified work |
Primary resources
Section titled “Primary resources”- Microsoft: common web application architectures.
- Cockburn: original ports and adapters article.
- Palermo: onion architecture, part 1.
- Martin: clean architecture.
- Spring Modulith: module fundamentals and structural verification.
- Amazon Builders’ Library: idempotent APIs.
These sources establish terminology. Our workload, thresholds, trade-off judgments and proposed ecosystem experiments are course assumptions, not conclusions measured in those sources.