Macro Architecture 是一套面向系统级决策的架构工具，工作在同一高度上：这个系统应该呈现什么形态？它由两个互补的方法组成。
用途
第一个方法是架构风格选择。给定一个系统、服务或功能及其驱动性需求，判断哪种宏观架构风格（或混合风格）更合适，并说明选择该风格时需要注意的警告事项。该部分内容来自 Mark Richards 的《Software Architecture Patterns》第2版。
第二个方法是“硬核部分”分解。当系统正在被拆分、合并或重塑时，判断各种权衡实际会推向哪个方向，并以当前代码和运行时证据为锚点。该部分内容来自 Ford 与 Richards 的《Software Architecture: The Hard Parts》。
适用场景
当需要为新系统选择整体形态，或对现有系统进行合理性检查时，使用风格选择方法。当决策核心是“把系统拆开还是重新合起来”时，使用硬核部分分解方法。两者可以组合使用：先选定风格，再对分解方案进行压力测试。
该技能与 architecture-lens（关注手头代码中的代码级权衡、connascence、层次放置与内聚）、domain-driven-design（限界上下文边界、通用语言、跨上下文集成模式）以及 design-patterns（GoF 代码模式）不同。本技能选择的是宏观形态，而上述技能审查的是形态内部的代码与上下文。
使用方式
根据需求选择要阅读的参考材料：需要选择或评估整体架构风格时，阅读 references/style-selection.md；需要拆分、合并或重塑服务与数据所有权时，阅读 references/decomposition.md；两者都需要时，先选择风格，再仅评估其未解决的分解权衡。
使用当前代码、运行时证据和用户约束。最小且自洽的形态就是满足实际需求的形态。需要说明收益、成本和下一步具体动作。不要把常规代码改动变成系统重新设计。
权限与输出
决策或评审请求返回所选方法的建议。只有在用户请求授权实施时才进行实施。在 design-gate 下保持只读，返回 verdict: proceed|revise、blocking_findings、advisory_findings 和 required_changes。
ADR 记录
只有在同时满足三个条件时才使用 ADR：难以逆转、脱离上下文会令人意外、存在真实权衡。当三者都适用时，按现有 ADR 约定在 settle 时记录。分解方法中包含回退路径和辅助命令。
聚焦知识
只加载所选方法需要的材料：风格细节包括 layered、microkernel、event-driven、microservices、space-based；references/traps.md 用于在推荐分布式风格之前阅读；references/other-styles.md 用于主矩阵不适用或粗粒度服务可能足够时；references/catalog.md 用于分解、粒度、所有权、事务和工作流权衡；references/adrtemplate.md 用于撰写持久决策。