macro-architecture

宏观架构

两个互补的系统级工具，着眼于同一层面——这个系统应该采用什么形态？

• 风格选择——给定一个系统／服务／功能及其核心需求，哪种宏观架构风格（或混合风格）最合适？如果选择这种风格，书中会提醒哪些注意事项？（摘自 Mark Richards 的 Software Architecture Patterns, 2nd ed.。）
• 难点分解——在分解、合并或重塑系统时，结合当前代码和运行时情况，权衡因素实际指向哪个方向？（摘自 Ford 和 Richards 的 Software Architecture: The Hard Parts。）

选择新事物的整体形态（或检查现有形态是否合理）时，使用风格选择。决定是拆分系统还是将其重新组合时，使用难点分解。二者可以结合使用：先选择风格，再对分解方案进行压力测试。

不同于 architecture-lens（对你手头代码中的权衡／共现关系以及分层位置／内聚性进行评审）、domain-driven-design（限界上下文边界、通用语言、跨上下文集成模式）和 design-patterns（GoF 代码模式）。此技能选择宏观形态；其他技能则评审其中的代码和上下文。

选择决策方法

需求	阅读
选择或评估整体架构风格	references/style-selection.md
拆分、合并或重塑服务和数据所有权	references/decomposition.md
两者都需要	先选择风格，再评估尚未解决的分解权衡

使用当前代码、运行时证据和用户约束。满足实际需求的最小一致形态才是合适的。明确说明收益、代价和下一步具体行动。不要把常规代码变更升级成系统重设计。

权威性与输出

决策或评审请求应返回所选方法的建议。只有用户授权实施时才进行实施。在 design-gate 下，保持只读，并使用调用方的规范门禁结果。

三项条件必须全部满足，否则不要写 ADR：难以撤销、缺少背景时会令人意外，以及确实存在权衡。当三项条件全部满足时，在决策敲定时记录，并遵循现有 ADR 约定。分解方法包含备用路径和辅助命令。

在面试中，将决策、理由、约束和来源引用补充到现有决策记录中。此阶段不适用独立报告和实施相关流程。

聚焦知识

仅加载所选方法需要的材料：

• 风格详情：layered、microkernel、event-driven、microservices、space-based。
• references/traps.md：在建议采用分布式风格之前阅读。
• references/other-styles.md：主要矩阵不适用，或粗粒度服务可能已足够时阅读。
• references/catalog.md：分解、粒度、所有权、事务和工作流权衡。
• references/adrtemplate.md：编写持久决策记录时阅读。