Architecture Lens

Judge the shape of a system: which style fits, where service and data boundaries go, and what each choice costs. Module placement, cohesion, dependency direction, and scope belong to software-design-philosophy; container and event-stream topology to distributed-systems-patterns; bounded contexts to domain-driven-design; connascence inside a diff to the Connascence Pass in coding-review-simplify.

Anchor every claim in the current code and runtime: modules, schemas, migrations, deployment descriptors, contracts, queues, jobs. Prefer that evidence over remembered architecture. A local change does not need a map of the whole repository, and a routine code change is not a system redesign.

Trade-off pass

Use for any unresolved architecture choice. Settled decisions stay inputs unless new evidence invalidates them.

1. Name the 2–4 characteristics actually in tension here. Most decisions trade two against each other. More than four means the decision is not framed yet. Watch for an implicit characteristic the domain demands that no ticket names, such as auditability in finance.
2. List the real options. "Keep current" can be one. Don't manufacture alternatives: when a settled contract or repository constraint already determines the move, say so and stop.
3. For each option, state what it gains and what it gives up. Record an actual cost; never invent a drawback to fill a field.
4. Decide against the characteristics from step 1 and say why in one sentence. The reasoning is the deliverable.

Apply the Least Worst Rule: do not ask which option is best; ask which one does the least harm for this domain, team, data model, and operating environment. A recommendation that names no harm has not finished the analysis.

If the decision creates a rule future code could silently break ("billing never reads the orders schema"), propose the smallest automated check that fails when it drifts, and add none for rules nobody is at risk of breaking.