Architecture Pattern Selection

Choose the smallest sufficient architecture justified by current demand, a constrained resource, ownership, and an observable upgrade trigger. Treat patterns as options with lifecycle costs.

Selection Workflow

1. State the protected behavior, current demand evidence, constrained resource, hard requirements, and decision horizon.
2. For a new or materially changed persisted architecture boundary, read references/architecture-decision-economics.md and compare the status quo, the smallest sufficient option, and a structural investment.
3. Read references/architecture-pattern-catalog.md for the pattern families relevant to the proven constraint.
4. Define the selected option's relevant dependency direction, state and data ownership, caller contracts, and evidence. Detail the failure containment, rollout, or recovery dimensions the boundary actually exercises.
5. Record the chosen option, material rejected alternatives, lifecycle-cost owner, and observable upgrade trigger.

Selection Rules

• Choose a maintainable option for the declared decision horizon, and add a larger pattern when its trigger is observed while delay preserves a safe migration path. Apply development-standards (Business Feedback Before Supporting Machinery) for sequencing a thin real business path ahead of support machinery.
• Introduce richer domain models, layers, or coordination for actual rules and coupling; simple use cases stay direct.
• Prefer an existing boundary or a reversible local extension when it satisfies the approved goal.
• Require demand or constraint evidence before adding distribution, asynchronous coordination, new infrastructure, speculative seams, or independent operational surfaces.
• Assign operational cost and decision authority to an explicit owner, place responsibility where the repository, team, runtime, language, or provider ecosystem has the lowest relative opportunity cost, and call out costs shifted to callers, operators, or future maintainers.
• Treat security, compliance, data-loss, and externally mandated reliability requirements as hard constraints rather than optional benefits in a scorecard.
• Decide with causal evidence, explicit discard reasons, and measurable triggers.

Interface And Domain Boundaries

When shaping module interfaces, test seams, domain terminology, or caller contracts, read references/interface-and-domain-language.md.

When the decision concerns handlers, services, repositories, framework isolation, inward dependency direction, or cross-boundary tests, read references/clean-boundaries.md.

Keep interfaces small and behavior-bearing, and create seams for proven variation or caller-visible test contracts.

Decision Result

When this skill owns an architecture decision, lead with the selected option and show only the evidence for why it fits current demand and the constrained resource, why simpler and more structural alternatives were rejected or deferred, who owns state, failure handling, lifecycle cost, and future evolution, which executable oracle protects the boundary, and what observable trigger justifies the next increment.

Reuse Before Taking Ownership

For a material open choice at a boundary, run the reuse check in design-change (Design) and development-standards (Local Dependency Selection) first. This Skill owns the boundary and economic comparison that follow: identify the missing responsibility, prefer a thin integration over duplicating mature state, protocol, or lifecycle machinery, and compare total lifecycle cost in references/architecture-decision-economics.md. Bespoke work may win on demonstrated reliability, licensing or platform fit, integration, or performance; state the actual gap and ownership tradeoff, after checking the project, host, and ecosystem for the capability.