软件架构设计指导
内容提要
本文讨论软件架构设计：架构用于同步团队认知、提前暴露风险。架构师负责定义质量属性与约束、把控全局、平衡成本与可用性、管理技术债务。前期架构设计约占工期20%，系统越大投入收益越高。设计应遵循最小代价、最小意外、DRY、单一职责、闭包、服务自治、单向依赖等原则，可用DDD拆分微服务，并用C4模型绘图、ADR记录决策，最后通过评估会检验方案。
延伸解读
架构设计投入多少时间？20%并非固定答案
文章引用Barry Boehm的研究指出，架构设计约占项目工期的20%时达到最佳平衡点，但这一比例随系统规模变化：大型系统（约一千万行代码）可投入37%，小型系统（约一万行代码）不应超过5%。这意味着团队不应机械套用20%，而应根据系统规模、需求波动和复杂度调整。对于需求可能大幅波动的项目，文章建议推迟关键决策并采用轻量级设计。
架构师的核心职责：定义质量属性与平衡取舍
文章明确架构师与产品经理的分工：产品经理定义功能特性，架构师定义系统的质量属性和约束。架构师还需把控全局，考虑人员、过程、产品需求等非技术因素，并在成本与高可用性、成本与实现优雅之间做取舍。技术债务无法避免，但需要判断哪些立即解决、哪些本次交付解决、哪些未来解决，甚至有时主动引入债务换取更快交付。
用C4模型画图：推荐层级与常见误区
C4模型提供上下文、容器、组件、代码四个抽象层次。文章推荐大多数团队使用系统上下文图和容器图，组件图不推荐给大多数团队，代码结构图仅用于最重要或最复杂的组件。常见误区包括过度关注细节、忽略系统间交互、与UML混淆、未考虑受众以及忽略安全和性能。绘制时应目标清晰、使用一致标识符、保持简单并易于更新。
ADR记录决策动机，避免后人闷头接受或绕过
文章强调架构决策记录（ADR）的价值在于保存决策背后的动机，否则后人只能闷头接受或绕过历史决策，可能错过调整机会或无意搞砸。ADR至少应包含问题描述、约束、假设、相关决策/原则、备选方案、决策及状态。粒度上，太细或太宏观的决策不适合用ADR，例如新增API可通过代码提交备注记录。ADR应尽可能开放可见并纳入配置管理。
Q&A
软件架构设计应该占项目总工期的多少比例比较合适？
根据Barry Boehm的研究，架构设计时间约占项目总工期的20%时达到最佳平衡点。此时架构设计时间与返工时间之和最小。系统规模越大，前期架构设计的收益越高：大型系统（约一千万行代码）可将37%的时间用于架构设计，而小型系统（约一万行代码）不应超过5%。
架构师的主要职责有哪些？
架构师的主要职责包括：从工程角度定义系统的质量属性和约束；把控全局，综合考虑技术、人员、过程、产品需求等因素；在成本与高可用性、实现优雅之间做平衡；管理技术债务，决定哪些债务立即解决、哪些延后或引入；明确利益相关方、业务目标、整体解决方案、技术选型、团队技术能力及最大风险等核心问题。
C4模型包含哪四个层次？分别适合谁看？
C4模型包含四个层次：1）上下文图（Context）：展示系统与外部系统及用户的交互，适合所有技术人员和非技术人员；2）容器图（Container）：展示系统内部的可部署单元及其技术选型和通信，适合开发团队及运维人员；3）组件图（Component）：展示容器内组件的职责和交互，适合架构师和开发人员；4）代码图（Code）：展示组件内的代码实现，适合架构师和开发人员，但通常不推荐大多数团队使用。
什么是架构决策记录（ADR）？它应该包含哪些内容？
架构决策记录（ADR）是用于记录架构决策背后动机的文档，帮助理解历史决策的前因后果。它至少应包含：问题描述（要解决什么问题及为什么现在解决）、约束（预算/时间线/资源等限制）、假设（决策时无法验证的假设）、相关的架构决策/原则、备选方案（每个方案的后果/代价）、决策（最终选择的方案及其后果/代价）、状态（草稿/待评审/已通过）。
如何评估软件架构设计方案的好坏？
可以组建评估会，使用打分表格（1-5分）从多个维度评估：以定义的质量场景和约束为准则；评估系统关键指标；考虑风险数量、不确定问题数量、团队态度、完成时间、适应性、技术债务等；评估满足成本要求或进度目标的可能性；评估团队技术能力是否适配。同时写出七个不确定问题的答案，确定后续行动要点并同步。注意架构设计没有绝对好坏，只有是否适合当前业务。
如何用DDD拆分微服务？具体步骤是什么？
采用DDD战略设计指导微服务拆分，主要分四步：1）找出领域实体和值对象等领域对象；2）找出聚合根，根据实体、值对象与聚合根的依赖关系建立聚合；3）根据业务及语义边界等因素定义限界上下文；4）每一个限界上下文可拆分为一个对应的微服务，同时考虑非功能因素。例如电商场景中，交易链路可划分出多个限界上下文，每个对应一个微服务。
