架构设计方法论与思维：从“画图”到“落地”的实战心法
面向一线开发和准架构师，讲清架构设计方法论：需求分析、架构立方体、功能性模型、运行性模型、资产复用、架构验证与面试策略。
1. 架构师的立命之本：画实实在在的架构工件
架构师有很多能力：沟通、曝光、项目管理、软技能、知识广度...但只有一个功能是只有架构师才具备的：
画实实在在的架构工件，制作大量实际的能够展现需求、能够落地的架构图。
这才是架构师的立命之本，真正的一技之长。
这一章重点讲流程：如何一步步展现需求、细化模块、最后变成落地的。工具简单介绍，更多是实战：把真正的图、真正的文档做出来。
2. 需求分析实战：WH 分析法 + 系统上下文 + 用例模型
2.1 需求贯穿整个系统生命周期（V 型图）
V 型图：
- 左边：业务需求 → 架构设计 → 产品开发
- 右边：功能验证 → 集成验证 → 接收度验证
- 核心：先了解用户需求，最后验证用户需求是否达到
深 V 浅 V 交替进行：
- 一个大 V 做完后，会有新需求迭代
- 新的架构设计迭代
- 再次验证原需求是否满足，新需求能否实现
JAD（联合应用设计）：
- 架构师、项目经理、研发经理、运维、开发、测试共同讨论
- 每次讨论：需求有没有变动？上一次迭代需求是否完整实现？有哪些残留需求？
2.2 需求实战：三张图 + 一段文字
第一张图：系统上下文图
- 描述系统在做什么，跟哪些用户、哪些外围系统打交道
第二张图：用例模型
- 通过一张图 + 一堆图 + 一堆文字描述
- 系统具体做的 What 是什么
- 跟 Which、Who 如何交互
- 交互内容是什么
第三部分：质量和限制（Word/Excel）
- 描述性语句：性能、高可用、扩展性、弹性伸缩能力
- 资金问题、项目时间问题、企业问题、监管要求
2.3 实战工具：OmniGraffle / Visio / ProcessOn / PPT/Word
工具选择：
- Mac：OmniGraffle
- Windows：Visio
- 在线：ProcessOn
- 传统：Rational Software Architecture（UML 工具）
- 最常用：PPT、Word、手绘
手绘 vs 电子版：
- 手绘：潦草、阅读性差、迭代不方便
- 电子版：迭代方便
关键：工具不是关键，表达思想才是关键。
2.4 实战案例：宠物寄存小屋
系统上下文图：
- 系统：宠物寄存小屋（方块）
- 用户：客户（观察动物）、宠物保姆（放食物）、小猫（入住）
- 外围系统：供水供电系统、垃圾箱（排泄系统）
用例模型（Use Case Model）：
- 客户：观察宠物状态
- 小猫：入驻、离开、吃喝拉撒、洗澡
- 宠物保姆：放食物、放毛线球
- 供水供电系统：供水、供电（加热）
- 垃圾箱：处理排泄
质量需求：
- 扩展性：管理 10 个小动物（分隔管理）
- 性能：洗澡水 1 分钟内完成（水加热很快或预先加热）
限制需求：
- 成本：小于 1000 元（小宠物店投资低）
关键点：
- 系统上下文：描述系统跟外面系统/用户的关系
- 用例模型：描述系统要实现多少个 What 才能满足要求
- 每个用例必须有触发源（外围系统/外围用户），没有触发源的需求不是真正的需求
3. 架构立方体：六个视角看架构
3.1 盲人摸象：不同视角看到不同视图
盲人摸象：
- 摸到屁股 → 像绳子
- 摸到腿 → 像柱子
- 摸到鼻子 → 像花洒
不同视角 = 不同观点（View）：
- 不能说对与错，站在某个角度是对的，全局看就不对
- Viewpoint（视角）：所有架构图、架构文档都是为了描述这个“大象”
- 大象是立体的、鲜活的，必须通过不同视角进行切片才能描述
3.2 六大视角：应用、技术、功能、运行、逻辑、物理
第一类：应用视角
- 代码用什么语言开发，开发出来做什么功能
- 例如：Java/C#/Python 开发的应用代码，做什么具体功能
第二类：技术视角
- 跟应用本身无关，通用技术
- 例如：中间件、数据库、用户认证授权审计（AAA 系统）
- 应用 vs 技术：
- 商品中心 = 应用
- 商品库 = 技术
第三类：功能视角
- 描述 Who、How、What
- 实现用例模型里的所有问题
- 例如：商品中心的 CRUD 功能
第四类：运行视角
- 描述 Where、When（运行分布形式）
- 什么样的时间、什么样的地点进行运行和管理
- 例如：分布式发布、跨城市、跨省、单元化思路
第五类：逻辑视角
- 技术定型了，产品未定型
- 只聊技术，不谈产品，不谈钱
- 例如：OpenID 公有用户认证系统（5 种解决方案：3demo、3soo、腾讯、阿里、微软 Outlook、GitHub 开源）
第六类：物理视角
- 产品定型了
- 有收费、有成本、有盈利模型
- 例如：选择腾讯开放平台的认证功能（跟微信、QQ 对接）
数据服务例子（贯穿六个视角）：
- 使用场景（产品中心/用户中心）→ 应用视角
- 解决方案（NoSQL/关系型数据库）→ 技术视角
- CRUD 过程 → 功能视角
- 跨多个机柜分布式、最终一致性 → 运行视角
- Spring Boot + MongoDB（不收费）→ 逻辑视角
- Docker 发布到阿里云 ACK + 云数据库 MongoDB 版（付费）→ 物理视角
3.3 需求到模型的映射
经典映射：
- 功能性需求 → 功能性模型
- 质量、限制 → 运行性模型
延伸映射（资深架构师）：
- 考虑功能性模型时，也考虑限制
- 考虑运行性模型时，重新评估是否实现了所有用例模型、功能性需求
- 通过交叠形成迭代思路
4. 功能性模型：三步走
4.1 第一步：定义模块（高内聚、低耦合）
模块 = 组件（Component）= 模块（Module）
内聚（左手原则）：
- 功能内聚 > 顺序内聚 > 通信内聚 > 过程内聚 > 时间内聚 > 逻辑内聚 > 偶然内聚
- 内聚性由高到低，模块独立性由强转弱
- 尽量功能内聚，避免偶然内聚
耦合（左手原则）：
- 非直接耦合 > 数据耦合 > 标记耦合 > 控制耦合 > 外部耦合 > 公共耦合 > 内容耦合
- 耦合度由低到高，模块独立性由强转弱
- 尽量非直接耦合或数据耦合，避免内容耦合
模块划分力度（第三只手原则）：
- 系统/领域 → 子系统/子域 → 微服务 → 聚合 → 实体 → 值对象
- 力度从左到右越来越细，设计时间越来越长
- 推荐：从中间开始（子系统/子域级别）
- 子系统级别：5-10 个或 20 个左右
- 子系统内再划分：2-3 个或 5-10 个微服务
- 不需要考虑数据聚合、实体对应关系
4.2 架构草图（AOD：Architecture Overview Diagram）
手画一张架构草图：
- 应用交易系统：用户 → 展现层 → 记录和交易处理层 → 传统系统对接
- 零售业客户访谈交互系统：销售系统 + 办公室 + 电话系统 + 邮件系统 + CRM + 中间件 + 数据库
横向分层图：
- 用户层 → 应用层 → 网络层 → 中间件层 → 数据库层
- 应用层每个小圆圈 = 一个微服务
关键：怎么快怎么来，可以在后续过程中不停补充、更新。
4.3 第二步：模块细化（模块关系图 + 时序图）
模块关系图（Component Relationship Diagram）：
- 认证登录子系统例子：
- 认证登录应用服务器（核心应用服务）
- 外部服务（API，Open API）
- 目录服务（LDAP/AD）
- 数据服务（审计日志）
- 关系：Use（调用关系）
时序图（Sequence Diagram / Component Interaction Diagram）：
- 工具：WebSequenceDiagrams.com 或 webchart.ihuha.cn
- 新用户注册流程：
- 客户 → Web 服务：访问
- Web 服务 → 认证登录应用服务器：注册
- 认证登录应用服务器 → 目录服务：新建用户
- 目录服务 → 认证登录应用服务器：完成（虚线回复）
- 认证登录应用服务器 → 数据服务：更新记录
- 数据服务 → 认证登录应用服务器：完成（虚线回复）
- 认证登录应用服务器 → Web 服务：注册成功
- Web 服务 → 客户：新用户创建完成
串行 vs 并行：
- 串行（大闸蟹从头串到底）：目录服务 → 数据服务（增强耦合，不好）
- 并行：认证登录应用服务器 → 目录服务 + 数据服务（解耦，好）
- 尽量采用并行，而不是全部串行
4.4 第三步：模块映射（Buy vs Build）
映射到产品：
- Buy：能买的考虑买（商业产品、开源产品）
- Build：没钱买或企业架构建议自建（掌控更好）
关键点：
- 把实际模块需求映射到一个产品上
- 映射完后，不用做过多架构设计
- 参考原架构、开源解决方案、成熟商业产品
5. 运行性模型：部署单元 + 架构转换
5.1 部署单元拆分（DU：Deployment Unit）
四大部署单元：
- 展现单元（Presentation）：跟用户展现、交互相关
- 执行单元（Execution）：实际业务逻辑执行
- 数据单元（Data）：数据存放、管理、生命周期
- 安装单元（Installation）：如何安装到指定位置
认证登录系统例子：
- 展现单元：登录界面（Web Service 提供静态登录界面）
- 执行单元：认证登录应用服务（认证和登录过程）
- 数据单元：
- 账号目录（LDAP/AD）
- 审计日志（数据服务）
- 安装单元：认证应用安装（部署认证登录应用服务器）
注意：不是所有模块都要拆解成四个单元，有些模块只对应一个单元。
5.2 架构转换：三步走（乐高积木）
第一步：应用逻辑部署模型（ALOM：Application Logical Operational Model）
关键点：
- 定义场景和边界（城市、机房）
- 摆放节点（节点上放部署单元）
- 连通节点（网络连线）
实战例子：
- 认证应用节点：认证登录功能、登录界面
- 认证数据节点：账号目录数据
- 审计数据节点：审计日志
- 用户终端：客户（浏览器/手机 APP）
- 连线：虚分隔线（可互通，有延时、带宽限制）
第二步：逻辑运行模型（LOM：Logical Operational Model）
增加非功能性内容：
- 质量、限制 → 支撑平台
- 监控、数据备份、高可用、集群、分布式
- 扩展性、高性能 → 缓存、XYZ 轴拆解
- 运维、管理工具
实战例子：
- 账号备份（技术执行单元 TE1）
- 审计日志备份（技术执行单元 TE2）
- 安全接入（技术执行单元 TE3：安全防御、加密扫描、入侵检测）
从应用逻辑节点 → 应用 + 技术的完整逻辑节点
第三步：物理运行模型（POM：Physical Operational Model）
关键点：
- 软件硬件产品型号、公司产品名、技术细节
- 详细产品规格：CPU、内存、硬盘、操作系统
- 数量：可用性、扩展性、伸缩性都跟数量有关
- 节点关系：负载均衡、集群、分布式
- 网络节点：对外访问、网络带宽、网络互联
实战例子：
- 用户终端（Pad）→ 防火墙 → 路由器 → 负载均衡器（成对出现）→ 应用服务器（多个）→ 数据库服务（Oracle RAC 3 节点、Windows AD 域控双节点集群）
- 安全模块：入侵检测、蜜罐系统
- 网络：移动、联通、电信三家运营商承载
- 扩展到 1000 家门店：宠物店 1 × 1000
- 双活、多活、单元化：复制数据中心
关键：忽略部署单元（在 LOM 上达到最高潮），重点看节点摆放、互通、高性能、高质量、高安全。
6. 架构资产复用：方法资产 + 工件资产
6.1 方法资产
原则：
- 单一原则、开闭原则、依赖倒置原则、好莱坞原则
- 微服务策略：有状态变无状态、前后端分离、分布式
模式（模板/风格）：
- 数据流风格：批处理、管道过滤器
- 调用返回风格：主程序/子程序、面向对象、层次结构
- 独立构建风格：进程间通讯、事件驱动
- 虚拟机风格：基于规则的系统、解释器
- 仓库风格：数据库、黑板系统
经典模式：
- 分层架构、事件驱动架构、微内核、生产者-消费者
框架（方法论）：
- Architecture Thinking（架构师思维）
- ABSD（基于架构的软件开发）
- DSSA（特定领域的软件开发）
生活类比：做巧克力/饼干用模板，倒进去加热就能做出形状。选择架构风格/模式，自然有标准架构图、参考架构、库代码。
6.2 工件资产
现成的库、开源源码：减少开发过程和难点
工具：
- 标准 IDE 平台、插件
- CI/CD 流程、CI/CD 资产
- 简化发布、编写编译、生产系统部署
参考架构和架构积木：
- 云平台参考架构例子（IBM + 咨询公司）：
- 左边：云平台如何跟用户交互
- 右边：如何跟管理员交互
- 下面：基础架构如何搭建
- 中间：基本服务、核心支撑层、核心业务服务层
- 参考架构文档：总图 + 详细小图 + 文字描述 + 功能 + 非功能注意点 + 行业解决方案 + 坑如何回避 + 关键点如何保持
6.3 资产价值
项目加速：
- 互联网时代是快鱼吃慢鱼，没时间慢慢设计
- 找参考架构、模板、基本原则，快速对应需求
避坑：
- 上云、大数据、人工智能坑很多
- 参考架构、模板、原则指引哪里可能出现问题、如何规避
减少意见冲突：
- 架构师、研发总监、项目总监、产品总监容易产生意见冲突
- 拿行业参考架构、行业架构数据原则和模板作为基准沟通
- “别人都能做成功，我们也相信能成功”
7. 架构验证：Doing the Right Thing Right
7.1 系统验证（System Verification）
第二个 Right：你造的这个桥会不会崩溃？能不能真正实现跨河互通？
7.2 系统确认（System Validation）
第一个 Right：你在小渔村架出来的是金门大桥还是 10 米见宽的小木桥？是不是满足业务要求、用户要求？
7.3 验证方法
JAD（联合架构设计）：
- 产品经理、架构师、研发负责人、运维工程师（SRE）配合
- 反复关注：架构是不是做对了？是否满足用户需求？
- 推荐：比较亲和的设计方法
ARB（架构评审委员会）：
- 大企业设立架构组（主架构师/首席架构师领队）
- 每周/每两周评审架构项目
- 架构开始开发设计前评审、产品代码上线前评审
- 适合大型项目：防止架构漏洞，但可能导致部门间摩擦
测试：
- 单元测试、系统测试、集成测试
- 用户验收测试（UAT）：
- 甲方：找实际用户感受系统
- 乙方：客户（金融企业、电信企业）帮你验收
7.4 RAID 工件（架构验证核心）
R：Risk（风险）
- 记录所有潜在风险
- 验证风险是否发生、被缓解、被规避
- 发现新风险（集成测试、上线前准备测试）
- 风险变成问题时，回顾风险规避策略
A：Assumption（假设）
- C 轮投资到位（1 亿元/1 亿美金）→ 假设可能不成立
- 架构设计原则依赖于行业规范 → 假设行业规范改变
- 记录假设，之后发现假设失误时能及时调整
I：Issue（问题）
- 记录项目进展问题、产品验收问题
- 产品跟用户最终需求背离时记录
- 用户验收时，让用户把所有吐槽内容记录在问题列表
D：Dependency（依赖）
- 减少依赖：应用启动依赖用户认证平台 → 如果认证平台无法启动，应用也无法启动
- 业务依赖解耦：
- 服务 A 依赖服务 B：采用熔断、快速响应机制切断依赖
- 反腐层：B 的 API 版本经常变换 → A 里做反腐层，进行内容转换
- 技术依赖：
- 模块 A 依赖 RocketMQ，模块 B 依赖 Kafka → 技术栈不一样，无法沟通
- 记录所有技术栈依赖、IT 依赖、业务依赖、应用依赖
8. 架构设计误区：大家来找茬
8.1 误区一：只关注功能性，忽略非功能性
图书馆管理系统例子：
- 只有用例模型、时序图、类图（全部功能性）
- 缺少：质量、限制、网络设计、节点连通、部署、非功能性（安全性、可靠性、稳定性、扩展性）
8.2 误区二：细节过度，缺少高屋建瓴的抽象
问题：
- 全程都是微观设计（鲁棒图、时序图、类图很详细）
- 缺少：架构草图、总体网络框架图、总体需求总框图、系统上下文图
建议：总分总或至少是总分，先有总图、总设计，再有细节设计。
8.3 误区三：视角混杂
游戏项目架构图例子：
- 物理运行模型图里没有服务器、容器，却有 APP 名称（商城、订单、支付、用户）
- APP 名称应该出现在组件图（功能性架构图）里，不应该出现在物理运行部署图里
- 问题：功能性模型跟运行性模型混编
建议：如果是架构草图可以随意，但如果是最终部署架构图或功能性模型架构图，不能视角混杂。
8.4 误区四：过度设计（九连环游戏）
问题：
- 系统非常精妙，每个环节都精美，几乎无可挑剔
- 采用冷门技术、大量定制化、组件间紧耦合、过度设计
缺点：
- 不容易找到替代者（架构师/主要程序员离职后难替代）
- 不适合交流（冷门，无法用一两句话解释清楚）
- 很难迭代（需求变化时，加一个环节都不方便）
- 下一个版本可能需要全部铲掉重新来
8.5 误区五：永远用擅长的技术
ZooKeeper 擅长者例子：
- 大数据平台 → Hadoop + ZooKeeper
- 搜索引擎 → Solr + ZooKeeper
- 消息队列 → Kafka（跟 ZooKeeper 紧密配合）
- 容器平台 → Mesos（集群管理配置信息存在 ZooKeeper 上）
- 统一一套 ZooKeeper 集群管理所有分布式系统的仲裁、存储、键值信息
问题：
- 永远在用擅长的技术，忽略用户需求
- 不是从用户需求角度选择架构，而是通过“我擅长什么就选择什么”
- 对未来架构演进、适应变化的需求很不利
建议：学会更多不同的架构选择选项，根据用户需求进行架构选择。
9. 面试实战：现场画图
9.1 第一题：如何通过用例模型来分析项目需求？
要点：
- 需求分析：先画系统上下文（系统要干什么，大体抽象）
- 用例模型：每个用例、每个具体功能，用例图展现
- 外部用户、外部系统如何跟内部系统沟通，实现哪些功能
拿高分：
- 找到白板/黑板，现场手画
- 以前做过的实际项目：用例如何设计、系统上下文如何评估项目需求范围
- 中间碰到的难点/坑、深刻想法和分享
- 现场实际画图 + 实际项目案例 → 跟面试官产生共鸣
9.2 第二题：架构设计中用到过哪些工件，如何关联？
要点：
- 很多工件：图、文档、规范
- 串成一条线：多视角、架构立方体
- 从需求到功能到运行模型，一步步串联
拿高分：
- 结合实际：不仅讲流程，现场挑一两个工件在白板上展现
- 给面试官感觉：不光了解流程，而且有实战深度
9.3 第三题：如何组织架构验证，确保设计满足质量要求？
要点：
- 不光架构验证，还要保证质量
- 考虑输入（非功能性质量、功能、限制）、输出（架构设计输出、应用代码输出、部署项目系统输出）
- 验证是否 Doing the Right Thing Right
拿高分：
- 结合实际案例：具体评估过程
- JAD：联合研发组负责人、运维、产品经理，共同进行架构设计、实现、测试、评估
- ARB：架构评审委员会在项目前期后期做两道门槛
- 组成派功力：实际工件输出
- 风险评估输出
- 问题列表输出
- 假设输出
- 依赖评估输出
三道题总结：
- 一题考需求分析（用例模型）
- 一题考工件关联（架构立方体）
- 一题考架构验证（RAID）
10. 总结：从需求到落地的完整流程
需求分析：
- 系统上下文图 + 用例模型 + 质量限制
功能性模型：
- 定义模块（高内聚低耦合）→ 模块细化（模块关系图 + 时序图）→ 模块映射（Buy vs Build）
运行性模型：
- 部署单元拆分（展现/执行/数据/安装）→ 架构转换（ALOM → LOM → POM）
资产复用：
- 方法资产（原则/模式/框架）+ 工件资产（库/工具/参考架构）
架构验证：
- RAID（风险/假设/问题/依赖）+ JAD/ARB + 测试
关键：通过架构立方体六个视角，从需求到功能到运行，一步步把架构图画清楚、把文档写清楚，最终实现可落地的架构和系统。
11. 延伸思考
- 挑选一个复杂的架构项目，用新学到的架构图思路
- 通过 UML 画图方法、架构立方体，把需求、功能性、运行模型都画清楚
- 把最终架构图分享在 QQ 群，跟小伙伴聊一聊，看看有没有地方能进一步改进
把架构师的基本功练扎实，把匠心精神练出来。
