architecturelisted

# Architecture ## Iron Law `ORGANIZE BY WHAT CHANGES TOGETHER. BOUNDARIES EXPOSE CONTRACTS, NOT INTERNAL STEPS.` ## When to Use - Choosing between feature-oriented organization and horizontal controller/service/repository/DTO layers. - Choosing shared project, package, or module boundaries, bounded contexts, and public surfaces. - Choosing API style or data store family before a specialist skill owns the detailed shape. - Deciding whether DDD tactical patterns earn their keep. - Reviewing code where one behavior is scattered across many files for no technical reason. ## When NOT to Use - Data shape, invariant, and effect discipline; use `domain-modeling`. - Public HTTP contract details; use `api`. Physical schema; use `database`. - Reshaping existing code while preserving behavior; use `refactoring`. - Local file moves or private helper extraction that create no shared boundary: explain the choice and proceed. ## Rules 1. Feature behavior, data shapes, invariants, and tests live close enough to change together, and one focused behavior can be run without invoking the whole suite. 2. Functions do one thing, stay around 25-30 lines, and keep conditionals and loops under three nesting levels. Guard clauses, extraction, or composition come before another nested branch. 3. Horizontal layers exist only for a real boundary: process, deploy, trust, persistence, transport, or proven duplication. A layer that scatters one behavior by default is harmf