Arch
Use when design problem broader than one pattern. Need pick right architectural lens first.
Keep arch as single entrypoint. Load only relevant reference file for problem at hand.
Pick the Right Reference
| If problem is mainly about... | Read |
|---|---|
| domain language, invariants, model clarity | references/ddd.md |
| layers, dependency direction, adapters | references/clean-arch.md |
| responsibilities and abstractions | references/solid.md |
| recurring impl shapes | references/patterns.md |
| system design decisions and rollout shape | references/sdd.md |
| more than one of above | start with one, then read next |
Shared Rules
- keep business rules explicit and testable
- push IO and framework details to edges
- prefer composition before deep inheritance trees
- add abstractions only when they reduce real duplication or coupling
- choose simplest structure that preserves clarity
Quick Checks
- domain model getting muddy -> read
references/ddd.md - layers leaking into each other -> read
references/clean-arch.md - one module doing too much -> read
references/solid.md - need repeatable shape for recurring problem -> read
references/patterns.md - need capture system design before impl -> read
references/sdd.md
Workflow
- identify dominant architecture problem
- read only matching reference file
- apply smallest structure that solves that problem
- combine references only when design truly spans multiple concerns
Adjacent Workflows
- use
qualitywhen want TDD to drive structural changes safely or RCA to diagnose failures around boundaries and design