Rubric: L-ARCHITECTURE
Lens: L-ARCHITECTURE · Density: D-LOW (Top N=10) · Axes: MNT, MOD, RDB
Purpose
Judge whether abstractions and boundaries clarify or obscure the domain; detect conflicting architectural patterns; illuminate major systems.
Criteria (Top N)
- Boundary clarity — modules map to responsibilities; cyclic deps called out.
- Abstraction honesty — interfaces exist for reasons; no “interface for every struct.”
- Pattern conflict — e.g. mixed layered + free-for-all imports; dual sources of truth.
- Complexity hotspots — algorithms/state machines needing sequence/flow diagrams.
- Extension points — how new features are meant to land (plugins, registries, codegen).
Non-criteria (avoid)
- Rewriting to a preferred architecture religion without evidence of pain.
- Naming bikesheds without maintainability impact.
Citations
| Work | Point |
|---|---|
| Simon Brown — C4 Model | Context/container/component views |
| Robert C. Martin — Clean Architecture | Dependency rule; boundaries |
| Eric Evans — Domain-Driven Design | Bounded contexts (when domain language is rich) |
| ISO/IEC 25010 | Maintainability / modularity characteristics |
Pros / cons of this rubric
| Pros | Cons |
|---|---|
| Forces conflict detection over purity cosplay | Top-N may miss a silent dependency cycle — pair with preflight graph if tools exist |
| Mandates diagrams for hotspots | DDD citations over-applied to CRUD tools — adversarial should retract |
Recommendation style
Prefer “two patterns coexist; pick one and migrate” over “adopt Clean Architecture everywhere.”