architecturelisted

# Architecture ## Iron Law `ORGANIZE BY WHAT CHANGES TOGETHER. BOUNDARIES EXPOSE CONTRACTS, NOT INTERNAL STEPS.` ## When to Use - Choosing between domain/feature-oriented organization and horizontal controller/service/repository/DTO layers. - Choosing shared project/package/module boundaries, bounded contexts, and public surfaces. - Defining internal boundary contracts: what shape crosses a module/component boundary, what assumptions are guaranteed, and what details stay hidden. - Choosing API style or data store family before a specialist skill owns the detailed shape. - Mapping data flow inside a component from external/service payloads through parsed internal shapes to output/render shapes. - Deciding whether DDD tactical patterns (aggregates, repositories, factories, domain services) 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`. - Database physical schema, indexes, or migrations; use `database`. - Reshaping existing code while preserving behavior; use `refactoring`. - Local file moves or private helper extraction that do not create shared boundaries; explain the choice and proceed. ## Core Ideas 1. Organize by what changes together. Feature behavior, data shapes, invariants, and tests should live close enough to change together. Keep production fil