Architect Lens

Two reusable lenses, distilled from Fundamentals of Software Architecture (Richards & Ford), for decisions made while writing code. Pick the lens that fits the moment — they compose.

Core principle that governs both: everything is a trade-off, and why matters more than how. If an analysis ends with a single obviously-correct option and no cost, you have not finished analyzing.

Distinct from architecturehardparts (service-decomposition / data-ownership / saga territory): this lens works at the code level — connascence and trade-offs in the code under your hands.

When to use which lens

• Decision / trade-off lens — you are choosing: an approach, a boundary, a library, sync vs async, monolith vs split, build vs reuse. → see Decision lens below.
• Connascence / coupling lens — you are evaluating existing code: a refactor, a review, "this feels tangled," deciding what to extract or merge. → see Coupling lens below.

Use both when a decision is about reducing coupling (e.g. "should I split this module?").

Decision lens (trade-off coach)