software-architecturelisted

# Software Architecture Use this skill to make and defend architecture decisions for **any** software — not just games. It replaces ad-hoc structure with a deliberate choice from two planes: - **Macro (structural):** how the whole app is decomposed and which way dependencies point. → [macro-structures.md](./macro-structures.md) - **Micro (tactical/runtime):** how a local code problem is solved. → [runtime-patterns.md](./runtime-patterns.md), plus the game backbone in [game/README.md](./game/README.md). ## The one rule everything else serves > **Choose the simplest structure that makes the next change easy.** Most pain comes from **over-application** of patterns, not ignorance of them. Every pattern adds indirection; indirection has a cost. When unsure, build the concrete, possibly duplicated thing and let the third real instance reveal the abstraction (see [principles.md](./principles.md)). ## Workflow when making an architecture decision ``` - [ ] State the problem in one sentence (e.g. "the domain imports the database", "input is hard-wired to actions", "state is duplicated and drifts") - [ ] Pick the plane: macro (whole-app shape) or micro (local mechanism) - [ ] Find the candidate in the matching table below - [ ] Read its card (intent, when to choose, when to avoid, per-domain example) - [ ] Confirm it's the lightest option that solves it (no simpler structure works) - [ ] Check dependency direction (inward) and boundaries (no leaks) - [ ]