核心观点：架构师是了解核心逻辑，而非陷入到细节。架构设计必须"追根溯源"，每一步都要能追溯到业务需求。成功的架构不是技术选型的堆砌，而是业务需求驱动下的系统性设计过程。

架构设计是一个完整闭环：需求分析（追根溯源）→领域建模（业务驱动）→确定关键需求（分水岭）→概念架构（顶层决策）→细化架构（模块+接口）→架构验证（原型验证）。核心是"追根溯源"——每一个设计决策都要能追溯到业务需求，每一个需求都要能追溯到系统目标。

一、需求分析：看透需求的三个原则

需求分析必须覆盖功能、质量、约束三个方面，缺一不可。只关注功能而忽略质量（性能、可用性）或约束（技术栈、合规），都会导致架构方向偏差。做好需求分析需要遵循三个原则：

原则1：看透需求——找全、理清矛盾、建立追溯

看透需求，不仅要把需求找全，还要把需求项之间的矛盾关系、追溯关系也都搞清楚。

需求要全：功能需求、质量需求、约束需求都要定义清楚。重视"功能"忽视"质量"，危险；重视"A质量"忽视应有的"B质量"，危险；忘了来自甲方乙方第三方的"约束"，危险。发现需求遗漏，就要尽快把遗漏的需求研究清楚。

矛盾关系：安全性和互操作性有矛盾，可扩展性和性能有矛盾，功能强大和预算有限有矛盾。识别出需求间的矛盾还没完，要给对策（例如性能最重要、可扩展性折衷，或者相反首先照顾可扩展性）、甚至重新评审需求的合理性。

追溯关系：这是需求、设计、实现等环节之间的"逻辑锚定"。就像盖楼，每一层砖块（下层需求/设计）都得锚定到上层"建筑蓝图"（上层目标/需求），保证上下对齐、不跑偏。

下层（需求范围、用例/功能）必须和上层（系统目标、需求范围）对齐，本质是"下层为上层服务，上下逻辑闭环"。反过来，上层也靠下层落地，形成"目标-范围-功能"的追溯链条，确保需求、设计"有理有据"。

追溯关系解决3类核心问题：

1. 防跑偏：比如"需求范围"靠"系统目标"兜底，避免需求做了一堆，却和客户真正要解决的问题（目标）没关系。
2. 防遗漏/镀金：遗漏→下层没覆盖上层，说明需求没拆解透；镀金→下层超出上层，做了客户/目标不需要的功能。
3. 分层对齐：需求本就分层（高层目标、用户能力、开发隐性需求），追溯关系让各层"上下同欲"。

实践方法：建"追溯链"——从顶层（系统目标/业务价值）开始，向下拆解到"需求范围→功能项→设计→代码"，每一步都问："这一步和上层的逻辑关系是啥？有没有对齐？"反向验证——做完下层设计/需求，反向追溯上层：“这些功能真的能帮上层目标落地吗？有没有多余/缺失？”

原则2：架构大方向正确——先设计概念架构

一个产品与类似产品在架构上的不同，其实在概念架构设计时就大局已定了。概念架构一级的设计更重视"找对路子"，像架构模式、集成技术选型等，比较策略化。它不关注明确的接口定义（之后的细化架构设计才是"模块+接口"一级的设计），对大型系统而言，这一点恰恰是必需的。

原则3：设计好架构的各个方面——多视图方法

架构师必须具备"忘却"的能力，避免涉及太多具体的技术细节，但是大型软件架构依然是复杂的。这就要求从多个方面进行架构设计，运用"多视图设计方法"。越是复杂的系统，越需要从多个方面进行架构设计，这样才能把问题研究和表达清楚。

二、领域建模：业务决定功能，功能决定模型

领域建模的精髓是"业务决定功能，功能决定模型"。领域模型不是纯技术抽象，而是由"业务与功能"驱动的业务本质映射。

领域建模的目的是：透过问题领域的重重现象，捕捉其背后最为稳固的领域概念，以及这些概念之间的关系。在项目前期，所建立的领域模型将为所有团队成员之间、团队成员和客户之间的交流提供共同认可的语言核心。随着项目的进展，领域模型不断被精化，最终成为整个软件的问题领域层，该层决定了软件系统能力的范围。

从项目前期伊始，软件架构师就应该是领域建模活动的领导者，这样可以避免"不同阶段领域模型由不同人负责"所带来的问题。

输入有两个：现在的功能（来自需求规格说明书）和未来的功能（可扩展性要求）。模型必须支撑当前功能，还要为未来功能预留扩展空间。

例如，电商"订单取消功能"源于"用户支付超时/不想买"的业务场景，因此领域模型中的"订单实体"要有cancelOrder()行为、“订单状态"属性，以及与"商品实体"的"库存关联关系”。

模型评审的唯一标尺是"功能支撑能力"：当前功能能否支撑？未来功能能否扩展？

三、确定关键需求：架构差异的分水岭

关键需求决定了架构的大方向，是架构差异的"分水岭"。

架构设计的本质是"用有限资源解决核心问题"。有些需求是"基础但不影响方向"的（如"用户修改昵称"），有些需求是"牵一发而动全身"的（如"双11峰值支持10万QPS"）——后者就是"关键需求"。

确定对架构关键的需求，不仅要求对功能需求（如用例）进行筛选，还要对非功能需求进行综合权衡，最终确定对软件架构起关键作用的需求子集。

确定关键需求的方法：关键功能 = 功能需求 + 约束需求；关键质量 = 质量需求 + 约束需求。约束需求是筛选器——同样的功能/质量，约束不同，关键需求完全不同。比如"支持100用户并发"vs"支持10万用户并发"，前者用单体架构，后者必须用分布式架构。

有经验的架构师不会一上来就关注如何定义"接口"，他们在大型系统架构设计的早期比较注重识别1）重大需求、2）特色需求、3）高风险需求，据此来决定如何划分顶级子系统、采用什么架构风格和开发技术、集成是否要支持、二次开发是否要支持。

大系统与小系统、你的系统与别人的系统，架构之所以不同，核心是关键需求不同。

四、概念架构：定方向而非抠细节

概念架构是直指系统目标的设计思想、重大选择。它是架构设计初期聚焦"方向、全局、核心逻辑"的顶层思维框架与决策集合。

概念架构的定位：先"定方向"，再"抠细节"。它不关心"模块A和模块B怎么通信"，只关心"为什么需要模块A和模块B"“这两类模块是否能支撑业务目标”“用什么模式把它们组织起来”。

概念架构要明确给出**“1个决定+4个选择”**：

1. 决定如何划分顶级子系统：划定架构的"骨架"（如电商系统：用户中心、商品中心、订单中心、支付中心）
2. 架构风格选型：决定架构的"基因"（单体/微服务/分层/事件驱动等）
3. 开发技术选型：确定技术栈"族系"（如Java Spring Cloud、React生态）
4. 集成技术选型：确定与外部系统的集成方式（RESTful API、MQ等）
5. 二次开发技术选型：明确第三方组件的二次开发方案

概念架构的核心组成包括4个关键决策维度：

1. 业务目标的"架构映射"：明确系统的"存在意义"。架构概念的起点不是技术，而是业务需求的顶层拆解。
2. 核心问题的"解决方案选型"：确定"用什么思路解决问题"。每个系统都有其核心痛点（如高并发、数据量大、多系统集成、业务迭代快等），架构概念需要明确"用什么架构模式/思路解决这些痛点"。
3. 技术栈的"方向选型"：确定"用什么技术族系"。架构概念不关注具体的"用Java还是Python"，但会确定技术栈的顶层方向。
4. 核心模块的"边界与交互逻辑"：确定"系统的骨架"。架构概念阶段不拆分具体模块，但会明确核心模块的"大颗粒度边界"和"交互关系"。

架构新手和有经验架构师的区别之一，在于是否懂得、并能有效地进行概念架构的设计。作为架构新手，尤其害怕碰上自己没做过的系统；系统较大时，一旦祭出"架构=模块+接口"的法宝却不太奏效，架构新手就往往乱了阵脚。

这5个决策是后续细化架构的"顶层约束"。

五、细化架构：多视图的全面设计

概念架构没有设计到"模块+接口"一级，而细化架构必须关注"模块+接口"。

一般而言，可以分别从逻辑架构、开发架构、运行架构、物理架构、数据架构等不同架构视图进行设计。本书推荐5视图方法，每个视图聚焦不同的目标受众和解决的核心问题：

1. 逻辑视图（Logic View）：回答"系统要实现什么业务功能"

核心目标：将业务需求转化为"系统的功能结构"，明确"做什么"，不关心"怎么做"（技术实现）。

关注重点：业务功能拆解、核心概念（领域模型）、模块划分、模块间的交互逻辑。

目标受众：产品经理、业务分析师、架构师（对齐业务需求）。

举例：电商系统的逻辑视图，会明确"用户中心、商品中心、订单中心、支付中心"这4个核心模块，以及"用户下单→订单中心调用商品中心查库存→调用支付中心完成支付"的功能流程——但不会说"支付中心用Java还是Python实现"“库存查询用什么数据库”。

2. 开发视图（Development View）：回答"开发团队怎么高效实现系统"

核心目标：解决"可扩展性、可重用性、开发效率"问题，明确"代码如何组织、团队如何协作"。

关注重点：代码目录结构、技术框架选型（如后端用Spring Boot、前端用Vue）、模块间的依赖管理、复用组件设计、开发规范。

目标受众：开发工程师、技术负责人（指导编码和团队协作）。

举例：电商系统的开发视图，会定义"订单模块的代码放在com.ecommerce.order目录下，依赖common-auth（通用认证组件）和common-db（通用数据库组件）“；同时规定"所有模块的接口都用RESTful风格，参数校验用统一的Validation框架”。

3. 物理视图（Physical View）：回答"系统部署在什么硬件环境上"

核心目标：解决"部署可行性、可用性、运维效率"问题，明确"系统的硬件拓扑的结构"。

关注重点：服务器节点（如应用服务器、数据库服务器、缓存服务器）、网络拓扑、部署策略（如数据库主从复制、应用服务器集群）、故障恢复方案。

目标受众：运维工程师、基础设施团队（指导部署和运维）。

举例：电商系统的物理视图，会设计"2台负载均衡器（NGINX）+4台应用服务器（部署订单/商品模块）+2台Redis缓存服务器（主从）+2台MySQL数据库服务器（主从复制）"。

4. 运行视图（Runtime View）：回答"系统运行时如何满足性能、可用性需求"

核心目标：解决"性能（响应时间、并发量）、持续可用性、容错性"问题，关注"系统运行时的动态行为"。

关注重点：请求处理流程、资源调度策略（如并行处理、分时调度）、性能优化手段（如缓存设计、异步队列）、容错机制（如超时重试、熔断降级）、负载均衡逻辑。

目标受众：性能测试工程师、架构师（保障系统运行稳定）。

举例：电商系统的运行视图，会设计"用户下单请求→负载均衡器→应用服务器→先查Redis缓存（若有库存直接返回，无则查数据库）→数据库查询后更新Redis缓存"；同时为了应对双11峰值，会用RabbitMQ异步处理"订单创建后的消息通知"。

5. 数据视图（Data View）：回答"系统的数据如何存储、流转、保障安全"

核心目标：解决"数据持久化、数据一致性、数据安全"问题，关注"数据的全生命周期"。

关注重点：数据模型设计（如数据库表结构、字段类型）、数据存储选型、数据流转路径、数据一致性保障（如分布式事务、数据同步策略）、数据安全措施（如数据加密、备份策略）。

目标受众：数据库工程师、数据分析师（保障数据可靠、可用）。

举例：电商系统的数据视图，会设计"订单表（order_id、user_id、amount等字段，MySQL存储）、用户行为日志（如浏览记录，MongoDB存储）、历史订单数据（超过1年的订单归档到Hadoop）“；同时规定"订单创建后，通过Canal同步数据到数据仓库，保障业务库和数据仓库的数据一致性”。

关键原则：多视图不是"孤立设计"，而是"相互关联"。各视图相互联动，共同支撑业务目标。比如：逻辑视图中"订单模块和支付模块独立"→开发视图中对应"两个模块代码独立，通过接口调用"→物理视图中"两个模块可部署在不同应用服务器，实现故障隔离"。

Grady Booch在其著作《UML用户指南》中指出："如果选择视图的工作没有做好，或者以牺牲其他视图为代价只注重一个视图，就会冒掩盖问题以及延误解决问题的风险。"只关注逻辑视图（功能）或只关注运行视图（性能），都会导致"顾此失彼"的问题。

细化架构的输入来自三个维度：所有需求（非仅关键需求）、概念架构的决策、领域模型。

六、架构验证：用原型验证风险

架构原型的核心目标不是"实现完美功能"，而是"针对性验证细化架构中的风险点"。

架构原型（Architectural Prototype）是针对软件架构"关键问题"的浓缩验证模型，它不追求功能完整，也不关注业务逻辑细节，而是聚焦于架构设计中"最不确定、风险最高"的部分（比如技术选型、核心流程可行性、非功能需求达标性等）。

其本质是"架构决策的试金石"：通过最小化的投入（时间、人力），验证架构设计中"拍板的大方向"是否可行，比如"微服务拆分后跨服务调用延迟是否满足要求""分布式缓存方案能否支撑高并发读"等——这些问题若等到系统开发后期才暴露，修复成本可能呈指数级增长。

架构原型和功能Demo完全不同：功能Demo追求功能完整，架构原型只聚焦"有风险的设计"，功能可以不完整、甚至有Bug，只要能验证风险即可。

只有"存在不确定性、可能导致架构失败"的设计，才需要开发原型。确定的设计（如"用MySQL存储订单数据"）无需原型；有风险的设计（如"用Redis+Lua脚本实现分布式锁防超卖"）必须开发原型验证。

对软件项目而言，往往需要开发出架构原型，并对原型进行测试和评审来达到验证目的。对软件产品而言，可以开发一个框架（Framework）来贯彻架构设计方案，再通过在框架之上开发特定的垂直原型来验证特定的功能或质量属性。

因此，从架构验证工作得到的不应该仅仅是"软件架构是否有效"的回答，还必须有可实际运行的程序：体现软件架构的垂直抛弃原型或垂直演进原型，或者是更利于重用的框架。这些成果为后续的开发提供了实在的支持。

架构验证的闭环：梳理高风险设计项→开发极简原型→测试验证→判断风险是否解决。如果跳过原型验证，一旦风险爆发，后期重构的成本可能是原型开发的10倍以上。

总结：架构设计的实践脉络

架构设计遵循三个原则，这也是做好架构设计的3个必要条件：

1. 首先，要看透需求，这是基础。架构师可能不是"需求"和"领域模型"的负责人，但也必须深入了解。
2. 中间，确定正确的概念架构。“关键需求"决定"概念架构”。
3. 最后，充分设计架构的各个方面。通过多视图方法"细化架构"，通过"架构原型"验证架构。

核心是"追根溯源"——每一个设计决策都要能追溯到业务需求，每一个需求都要能追溯到系统目标。只有这样，架构设计才不会偏离业务本质。

程序员向架构师转型，难在何处？难在必须要能开始"试着做起来"，并慢慢积累感觉，进而积累经验。“需求决定架构"之所以是一句废话，就是因为它没告诉开发人员"架构设计怎么做”。在没有积累任何经验和"感觉"的情况下，忽然被老板"委以重任"负责架构设计，都未必是一件好事。因为这次失败了，下次机会就没了。

如果你是程序员，又盼着有一天能做架构师，就要明白"经历设计在前，成为架构师在后"的道理。多看看别人的设计成果、多体会别人的设计过程、多试着自己来设计设计——这些方式都能促进对设计方法或技巧的领会。

参考：《软件架构设计》- 温昱