software-architecturelisted

# Software Architecture ## Purpose Architecture is the set of decisions that are expensive to change once code depends on them: where the boundaries are, which direction dependencies point, what is allowed to know about what. Everything else is implementation and can be rewritten cheaply. The goal is not elegance. It is to keep the cost of the *next* change roughly constant instead of growing with the size of the system. ## When to use - Before implementing anything that touches more than one system. - When deciding where a new piece of code belongs. - When a codebase has become slow to change, or a small change requires edits in many unrelated places. - When reviewing a design proposal. - Before adding a dependency between two subsystems that were previously independent. - When a system needs to support variation (platforms, content types, rules) that it currently hard-codes. ## When NOT to use - Prototyping to answer a question. Prototype code should be structured to be *deleted*, not extended. Applying architecture to a throwaway is waste. - Fixing a defect. Use `root-cause-debugging`; do not redesign under a bug fix. - Reorganising code that is not causing pain. Restructuring has cost and risk; "it feels untidy" does not pay for it. - Performance work. Use `performance-profiling-method`. ## Required context | Fact | Why it matters | |---|---| | What the system must do now | Architecture serves requirements, not aesthetics | | What is likely to change | Bo