architecting-code

Architecting Code

Evidence base: Robert C. Martin, Clean Architecture: A Craftsman's Guide to Software Structure and Design (Pearson, 2017). Chapter references cite Clean Architecture unless noted.

Load-bearing rule — architecture is measured by cost of change

Architecture is "the significant design decisions that shape a system, where significant is measured by cost of change" (Booch, via Henney, Foreword). Optimise the kinds of changes the system actually experiences to be cheap, not rare — and size the architecture to the problem, not to a textbook.

The Dependency Rule

• Source-code dependencies always point toward higher-level policy; details implement interfaces owned by the policy layer — the DIP mechanism that makes the rule enforceable (PART III SOLID summary; Appendix A ROSE)
• When crossing a boundary, invert the dependency so the caller holds an interface the detail implements (Appendix A, Union Accounting)
• High-level policy compiles with zero knowledge of UI, database, or framework types — only of the abstractions it owns (Ch 17; Appendix A 4-Tel Vectorization)

SOLID at the module level

• SRP — every module has exactly one reason to change, defined by one actor/stakeholder (Ch 7; PART III summary)
• OCP — add new behaviour by adding new code, not by editing existing, already-tested code (Ch 8; PART III summary)
• LSP — a subtype's contract must allow substitution anywhere the supertype is used, including in tests (Ch 9)
• ISP — never force a module to depend on interface members it doesn't use; unused methods still pin recompile/redeploy (Ch 10)
• DIP — high-level policy never imports concretions; details implement policy-owned interfaces; factories sit at the boundary (Ch 11)

Component cohesion (what belongs together)

• REP — Reuse/Release Equivalence — the granule of reuse is the granule of release; unreleased code is not reusable (Ch 13)
• CCP — Common Closure — classes that change together belong in the same component (component-level SRP) (Ch 13)
• CRP — Common Reuse — classes that are used together belong in the same component; never drag unrelated classes along (component-level ISP) (Ch 13)