architecture

Architecture (System Pattern Chooser)

Overview

Pick the smallest system/architecture pattern that addresses the pressure (reliability, consistency, domain boundaries, scalability).

Use code patterns for in-process structure; use system patterns when the problem is cross-process or cross-team.

Monolith edge case: If you're restructuring within a monolith without decomposing it into services (e.g., extracting modules, introducing internal boundaries, applying GoF patterns), use design instead. Use architecture when the monolith is being decomposed into separate deployable units, or when decisions span process/deployment/team boundaries.

Inputs / Outputs

Inputs: Archobs JSON — cluster coupling, leakage, risk scores (required); plan scope (if exists); forecast lifecycle data (if external deps involved). Outputs: Pattern selection with rationale, decision table, boundary diagram, implementation tactics. Consumed by design (in-process patterns), spec (contracts), plan (task ordering).

Workflow

1. Gather empirical data (required — wait for completion):
   • Reuse .archobs/file_metrics.parquet only when it is newer than the most recent commit and .archobs/run_manifest.json exists with status equal to complete; otherwise run archobs report --repo <path> --out .archobs --suggestions-provider rules and wait for the report to complete before continuing.
   • Read results: archobs show all --format json (or query archobs show risks, archobs show clusters individually).
   • Use cluster leakage data to identify where boundaries are already porous.
   • Use file-level risk scores to focus on the highest-impact areas.
   • Skip this step only if the repo is too small (< 10 files) for meaningful analysis.

0b. Ecosystem Pressure Check (conditional — run when the architecture decision involves adopting or replacing a technology, defining boundaries around external dependencies, or planning work with a time horizon > 6 months):