【架构设计方法论（3）】架构设计速查

一、需求分析

需求的三个方面

需求必须涵盖功能、质量、约束三个方面，缺一不可。

什么是"功能需求"？

• 定义：系统要做什么，即系统提供的业务能力
• 示例：用户登录、订单创建、商品搜索、支付处理

什么是"质量需求"？

• 定义：系统要做到什么程度，即非功能性的性能指标
• 示例：
  • 性能：响应时间≤200ms、支持10万QPS
  • 可用性：系统可用性≥99.99%
  • 安全性：数据加密、防SQL注入

什么是"约束需求"？

• 定义：系统开发/落地的限制条件
• 示例：
  • 技术约束：必须使用Java技术栈、必须兼容IE11
  • 合规约束：数据存储需符合GDPR、必须通过等保三级
  • 成本约束：服务器预算不超过100万/年

为什么三个方面缺一不可？

• 只有功能需求：可能忽略性能、安全等质量要求，导致系统无法实际使用
• 只有功能+质量：可能忽略技术约束，导致无法落地
• 只有功能+约束：可能忽略质量需求，导致系统性能不满足业务要求

需求分析的"两纵三横"框架

两纵（贯穿主线的支撑活动）：

• 需求沟通：持续与需方沟通、启发、验证，避免"闭门造需"（闭门造需危险大）

  • 什么是"闭门造需"？：开发方不跟需方沟通，自己想象需求，导致需求脱离实际业务
  • 为什么危险？：开发的功能用户不用、系统性能不满足实际业务、后期频繁返工

• 非功能需求确定：质量需求需持续跟进，是持久战，非一次性敲定

  • 为什么是持久战？：质量需求（如性能、可用性）在系统演进过程中会不断变化，需要持续跟进
  • 示例：初期"支持1000并发"即可，业务增长后需要"支持10万并发"，质量需求需要重新确定

三横（需求分析主线）：

1. 确定系统目标：明确系统要解决的核心问题

   • 输出：目标列表（如"提升用户购买转化率30%"、“支撑双11峰值流量”）

2. 研究高层需求：通过"范围+Feature+上下文图"三剑客梳理功能边界

   • 范围框图：定义系统边界，明确系统包含什么、不包含什么
   • Feature树：将系统目标层级化拆解为核心功能模块与具体功能点（如"用户管理"→"用户注册"、“用户登录”）
   • 上下文图：展示系统与外部系统/用户的交互关系

3. 建立用例模型：将需求转化为可执行的用例图+用例规约

   • 用例图：可视化展示系统功能与参与者的关系
   • 用例规约：详细描述每个用例的前置条件、主流程、异常流程、后置条件

需求跟踪脉络：

系统目标 → 高层需求（范围框图+Feature树+上下文图） → 用例模型（用例图+用例规约）

什么是"高飘"到"落地"？

• “高飘”：抽象、模糊的需求描述（如"提升用户体验"）
• “落地”：具体、可执行的需求描述（如"搜索接口响应时间≤200ms"）
• 转化过程：需求从抽象的业务目标，逐步细化为可执行的功能规格

需求从"高飘"到"落地"，成果项从"目标列表"到"范围框图+Feature树+上下文图"到"用例图+用例规约"，需求跟踪脉络清晰可辨——每一个细粒度需求，都能追溯到最初的系统目标。

追根溯源是成败关键

常见问题：

• 把用户随口说的需求当成最终需求，未追问真实场景
• 接到性能需求未确认是峰值还是日常，未追溯业务目标

后果：开发的功能用户不用、系统性能不满足实际业务、后期频繁返工

解决方法：追根溯源——确保需求有源头、有理由

什么是"需求源头"？

• 源头：需求最初产生的业务场景或业务目标
• 示例：
  • ❌ 错误：用户说"我要一个搜索功能" → 直接开发搜索功能
  • ✅ 正确：追问"你用搜索找什么？" → “找商品” → “为什么找商品？” → “想买便宜的商品” → 源头：业务目标是"提升用户购买转化率"

什么是"需求理由"？

• 理由：为什么需要这个需求，它解决了什么业务问题，支撑了什么业务目标
• 示例：
  • ❌ 错误：接到需求"系统要支持10万用户同时访问" → 直接设计高并发架构
  • ✅ 正确：追问"为什么是10万？" → “双11促销预期流量” → “这个数字来自哪里？” → “业务部门基于去年数据预测，目标是提升30%销售额” → 理由：支撑业务目标"双11销售额提升30%"

如何建立追溯关系？
通过需求跟踪脉络，建立"细粒度需求 → 用例 → Feature → 高层需求 → 系统目标"的完整链路：

示例追溯链：

系统目标：提升用户购买转化率，支撑30%营收目标
  ↓
高层需求：用户能快速找到想要的商品
  ↓
Feature：商品搜索功能
  ↓
用例：用户搜索商品（用例规约：支持关键词搜索、价格筛选）
  ↓
细粒度需求：搜索接口响应时间≤200ms（质量需求）

验证标准：

• 当开发质疑"为什么要做这个功能"时，能追溯到系统目标
• 当需求变更时，能判断是否影响系统目标
• 当测试发现问题时，能追溯到原始业务场景

 

二、领域建模

核心原则：业务决定功能，功能决定模型

建模逻辑：

业务需求 → 系统功能 → 领域模型

什么是"业务决定功能"？

• 含义：所有系统功能都源于业务需求，而非技术人员的想象
• 示例：
  • ❌ 错误：开发方觉得"该加个取消按钮" → 设计订单取消功能
  • ✅ 正确：业务场景"用户支付超时/不想买" → 需要订单取消功能 → 设计订单取消功能

什么是"功能决定模型"？

• 含义：领域模型是支撑功能实现的业务抽象载体，功能需要什么业务逻辑，模型就包含什么概念、行为与关系
• 示例：
  • 功能：订单取消
  • 模型设计：
    • 订单实体需要有"订单状态"属性（判断是否可取消）
    • 订单实体需要有"cancelOrder()"行为（执行取消逻辑）
    • 订单实体与商品实体需要有"库存关联关系"（取消后恢复库存）

关键要点：

• 模型不是纯技术层面的抽象，而是完全由"业务与功能"驱动的业务本质映射

  • 什么是"业务本质映射"？：模型反映的是业务领域的核心概念和规则，而非技术实现细节
  • 示例：订单模型反映的是"订单有状态、可以取消、关联商品"等业务规则，而非"订单用MySQL存储"等技术细节

• 模型必须支撑当前功能，并为未来功能扩展预留空间

• 模型为业务服务，而非技术主导模型

  • 含义：模型设计的出发点是业务需求，而非技术框架或设计模式
  • 反例：为了"用聚合根模式"而强行拆分实体，导致模型复杂化但业务价值不大

• 脱离业务功能的模型是"无源之水"，无法支撑实际业务

  • "无源之水"的含义：没有业务根源的模型，就像没有水源的河流，无法持续
  • 后果：模型无法支撑实际业务，最终需要重构

领域建模的输入

1. 现在的功能（来自《软件需求规格说明书》）

   • 模型必须能直接支撑当前已明确的所有业务功能
   • 例：需求有"订单拆分"，模型必须设计"订单实体"与"子订单实体"的组合关系

2. 未来的功能（可扩展性要求）

   • 模型要预留扩展点，避免未来功能迭代时需推翻重构
   • 例：未来支持多种订单类型，建模时用"泛化关系"设计"订单父类+各类型订单子类"
   • 可扩展性设计思想：泛化、值对象、引入等设计模式，为未来功能预留空间

评审依据：功能支撑能力

评审不能凭"技术优美度"（如"模型够不够简洁"“用了多少DDD核心概念”），而要回归"功能支撑能力"。

当前功能能否支撑？

• 方法：用已明确的功能反推模型，检查是否有缺失
• 示例："申请退款"功能需要：
  • 订单实体是否有"已支付"状态判断？→ 检查模型
  • 退款申请实体是否关联了"订单ID""退款金额"等必要属性？→ 检查模型
  • 若有缺失，模型需优化

未来功能能否扩展？

• 方法：用可扩展性要求验证模型，检查结构是否固化
• 示例："未来要加会员专属订单折扣"需要：
  • 订单实体是否能关联"用户会员等级"？→ 检查模型
  • 是否有"计算折扣金额"的扩展行为（或预留接口）？→ 检查模型
  • 若模型结构固化、无法新增关联，就是不合格的

 

三、确定关键需求

核心观点：关键需求决定架构大方向

重要前提：架构面前所有需求一律平等？不可能。

为什么需求不能一律平等？

• 不同需求对架构的影响权重天差地别
• 有些需求是"基础但不影响方向"的（如"用户修改昵称"），可通过常规设计实现，不会改变架构核心逻辑
• 有些需求是"牵一发而动全身"的（如"双11峰值支持10万QPS"），若不优先满足，后续架构再优化也无法支撑系统落地

什么是"关键需求"？

• 定义：对架构影响最大、决定架构"大方向"的需求（含关键功能、关键质量）
• 特点：若不优先满足，后续架构再优化也无法支撑系统落地

架构设计不是"满足所有需求"，而是"用有限资源解决核心问题"。

什么是"分水岭"？

• 含义：关键需求的确定这一步，是架构设计过程中"决定架构差异"的关键节点
• 作用：在这一步之前，所有系统看起来"差不多"；在这一步之后，不同系统的架构开始分化（大系统vs小系统、A平台vsB平台）
• 为什么是分水岭？：关键需求不同，架构方向就不同；关键需求相同，架构方向可能相似

关键需求的确定这一步是架构设计的"分水岭"，决定了架构的大方向。

关键需求的确定方法

关键功能 = 功能需求 + 约束需求（交叉分析）
关键质量 = 质量需求 + 约束需求（交叉分析）

什么是"交叉分析"？

• 含义：将功能/质量需求与约束需求进行组合分析，判断是否成为关键需求
• 方法：对每个功能/质量需求，结合约束需求，评估其对架构的影响程度
• 示例：
  • 功能需求"用户登录" + 约束"支持100用户并发" → 不是关键需求（常规设计即可）
  • 功能需求"用户登录" + 约束"支持10万用户并发" → 成为关键需求（需分布式架构）

核心机制：约束需求是确定关键需求的"筛选器"

什么是"筛选器"？

• 含义：约束需求决定了同样的功能/质量需求，是否成为"关键需求"
• 机制：同样的功能/质量，若约束不同，最终确定的"关键需求"会完全不同，进而导向不同的架构

具体示例：

• 功能需求：用户登录
• 质量需求：支持并发访问
• 场景1：约束是"支持100用户并发" → 不是关键需求 → 单体应用即可
• 场景2：约束是"支持10万用户并发" → 成为关键需求 → 必须分布式架构

为什么约束需求是筛选器？

• 没有约束时，所有需求看起来都"差不多重要"
• 有了约束后，某些需求因为约束的"放大效应"（如10万并发），对架构的影响被放大，成为关键需求
• 约束需求帮助识别"哪些需求真正决定架构方向"

示例：

• 基础功能（如"用户修改昵称"）：不影响架构方向
• 关键功能（如"双11峰值支持10万QPS"）：决定架构方向（需分布式架构）

架构差异的根源

大系统 vs 小系统：

• 小系统：关键需求是"开发快、维护简单" → 单体应用
• 大系统：关键需求是"高并发、数据安全" → 分布式微服务

同类型系统：

• A平台：生鲜即时配送 → 重点设计"仓配一体化模块"
• B平台：跨境电商 → 重点设计"海关接口适配模块"

差异根源：关键需求不同，而非系统大小或类型。

 

四、概念架构设计

定位：高层架构的战略核心

概念架构是高层架构成果的核心，框定了架构大方向，是甲方规划、乙方投标的评定关键。

什么是"顶层骨架与大方向"？

• 顶层骨架：架构的最顶层结构，如"系统划分为4个中心"（不是细粒度模块，而是大领域/大能力单元）
• 大方向：架构的整体策略，如"采用微服务架构"（不是具体技术选型，而是架构模式）
• 作用：为后续所有架构工作划定边界和方向，确保不偏离关键需求与系统目标

概念架构是架构的"顶层骨架与大方向"，决定后续所有架构工作的方向。

价值体现：

• 对甲方：规划系统建设路径的依据
• 对乙方：投标竞争的核心筹码

定义：直指关键需求的设计思想与重大选择

定义解析：

• “直指目标”：说的是输入，即概念架构设计要"直指"的输入就是"关键需求"
• “设计思想和重大选择”：说的是输出，即概念架构的输出是设计思想与重大选择

什么是"设计思想"？

• 含义：架构设计的核心理念和原则
• 示例：如"采用领域驱动设计（DDD）思想"、“遵循微服务拆分原则”、“采用事件驱动架构思想”

什么是"重大选择"？

• 含义：对架构方向有重大影响的决策，这些决策是后续细化架构的"顶层约束"
• 示例：如"选择微服务架构而非单体架构"、“选择分布式数据库而非集中式数据库”
• 为什么是"重大"？：这些选择一旦确定，后续架构工作必须遵循，改变成本极高

什么是"顶层约束"？

• 含义：概念架构做出的重大选择，成为后续细化架构设计时必须遵循的约束条件
• 作用：确保细化架构不偏离概念架构确定的大方向
• 示例：概念架构选择"微服务架构"，细化架构就不能设计成单体架构；概念架构划定"订单中心为独立子系统"，细化架构就不能将订单功能拆分到商品中心

输入：关键需求（含关键功能、关键质量）

工具（针对不同需求运用不同技能项）：

• 鲁棒图：梳理关键功能对应的核心业务逻辑与模块交互

  • 作用：通过"参与者、边界、控制、实体"等元素，快速梳理关键功能对应的核心业务逻辑与模块交互
  • 示例：电商"高并发下单"的关键需求，用鲁棒图可明确"用户→订单边界→库存控制→商品实体"的核心交互，为后续子系统划分提供依据

• 目标-场景-决策表：将质量需求转化为可落地的架构决策

  • 作用：针对关键质量需求，先明确"目标"（如高可用），再列举"场景"（如服务器宕机、网络中断），最后用"决策表"确定应对策略
  • 示例：目标"系统可用性≥99.99%“，场景"服务器宕机”，决策"自动切换到备用节点"

输出：1个决定 + 4个选择

输出成果	核心内容	示例
1. 顶级子系统划分	系统最顶层的模块拆分逻辑	电商系统：用户中心、商品中心、订单中心、支付中心
2. 架构风格选型	核心架构模式（单体/微服务/分层等）	多业务线独立迭代 → 微服务架构
3. 开发技术选型	核心开发技术栈方向	微服务 → Java Spring Cloud 族系
4. 二次开发技术选型	第三方组件的二次开发方案	第三方ERP → OpenAPI + 自研适配层
5. 集成技术选型	外部系统集成方式	微信支付 → RESTful API + 签名验证

 

五、细化架构设计

核心差异：从"方向"到"细节"

概念架构：聚焦大方向，输出宏观决策（如"订单中心采用微服务"），没有设计到"模块+接口"一级
细化架构：聚焦可落地，必须关注"模块+接口"一级

什么是"模块+接口"一级？

• 模块：系统的功能单元，如"订单中心"拆分为"订单创建模块、订单状态管理模块、订单查询模块"
• 接口：模块间的交互规则，如"创建订单接口（入参：商品ID、数量；出参：订单号）"“更新订单状态接口（入参：订单号、新状态；出参：操作结果）”
• 为什么必须到这一级？：只有明确到模块和接口，开发团队才能分工协作，系统才能实际落地

类比：概念架构类似"城市规划"（规划城市的功能分区和交通主干道），细化架构类似"建筑施工图"（每个区域内具体盖哪些楼、楼与楼之间的通道宽度和连接方式）。

关键对比：

• 概念架构设计的输入是"关键需求"，而不是泛泛的所有"需求"
• 细化架构要为"需求"而设计（覆盖所有需求）
• 细化架构要在"概念架构"的设计思想下进行

设计范畴：5个视图，15个任务

架构设计涉及的方面很广（模块切分、持久化格式、并行并发等都得管），架构设计师得是通才（要掌握的技能项较多），细化架构设计这一步体现得最充分。

什么是"通才"？

• 含义：架构设计师需要掌握多方面的技能，不能只懂某一领域
• 技能要求：
  • 既懂业务逻辑（理解业务需求），又懂技术实现（知道如何用技术实现）
  • 既关注功能（系统要做什么），又关注性能、安全等非功能需求（系统要做到什么程度）
  • 既懂代码设计（模块划分、接口设计），又懂部署运维（服务部署、负载均衡）
• 为什么需要通才？：架构设计需要从多个维度（逻辑、数据、开发、运行、物理）全面设计，单一领域的专家无法完成完整的架构设计

什么是"5个视图"？

• 含义：从5个不同维度（逻辑、数据、开发、运行、物理）全面设计架构，确保每个技术环节都有明确设计
• 为什么需要5个视图？：单一视图无法覆盖架构的所有关键方面，需要多维度协同设计

视图	关键任务	具体内容示例	作用
逻辑架构视图	模块划分、职责定义、依赖关系、接口设计	订单中心拆分为5个核心模块；定义"创建订单接口（入参：商品ID、数量；出参：订单号）"	明确系统功能单元组成与协作，指导开发团队的模块分工
数据架构视图	数据库选型、表结构设计、分片策略、缓存策略	选型MySQL/Redis；设计订单表结构（订单号、金额、状态等字段）；Redis缓存订单数据	确保数据存储高效安全可扩展，支撑业务数据的读写需求
开发架构视图	技术栈细化、代码目录规范、构建流程	微服务用Spring Cloud Alibaba；接口用OpenAPI规范；定义代码目录结构	统一开发标准，确保团队编码风格一致、技术选型可落地
运行架构视图	服务部署拓扑、负载均衡、熔断降级	订单服务部署3个节点；Nginx轮询负载均衡；配置熔断降级策略	保障系统运行时的性能与可用性，如通过多节点部署应对高并发
物理架构视图	服务器规格、网络拓扑、存储设备选型	服务器8核16G；内网/外网隔离；SSD用于数据库	衔接技术设计与硬件资源，确保架构在实际物理环境中可部署

输入来源

细化架构设计的输入既来自"需求成果"层面、也来自"高层架构"层面。

什么是"需求成果层面"？

• 含义：需求分析阶段产生的所有需求文档和模型
• 包含：功能需求、质量需求、约束需求、用例模型等
• 作用：细化架构必须覆盖所有需求，确保每个需求都有技术载体

什么是"高层架构层面"？

• 含义：概念架构设计阶段产生的顶层决策
• 包含：子系统划分、架构风格选型、技术选型等
• 作用：细化架构必须在概念架构的框架下进行，不能偏离顶层决策

1. 需求成果：所有需求（细化架构要为"需求"而设计，需覆盖所有需求，而非仅关键需求）

   • 关键对比：概念架构设计的输入是"关键需求"，细化架构的输入是"所有需求"

2. 概念架构：必须遵循概念架构的顶层决策（细化架构要在"概念架构"的设计思想下进行）

   • 约束关系：细化架构是概念架构的"落地执行者"，不能违背概念架构的决策

3. 领域模型：

   • 影响逻辑架构视图：领域模型设计——实体转化为模块，关系转化为依赖
     • 示例：领域模型中的"订单实体"转化为逻辑架构中的"订单模块"
   • 影响数据架构视图：存储格式设计——实体属性决定表结构，聚合关系影响存储策略
     • 示例：订单实体的"订单号、金额、状态"等属性决定订单表的字段设计

 

六、架构验证

核心观点：架构原型是验证工具，非功能Demo

架构验证的输出成果是"架构原型"。和一般的开发不同，架构原型的开发不是要完美地、无Bug地实现功能，而是在"细化架构"的总体指导下，仅把存在"风险"的那些设计尽早开发出来，然后通过执行测试等手段判断"风险"是否解决。

架构原型 vs 功能Demo：

• 功能Demo：展示"系统能做什么"，追求功能完整
• 架构原型：验证"架构设计行不行"，只聚焦有风险的设计

原型开发的目标：解决风险，非实现功能

筛选标准：只有存在不确定性、可能导致架构失败的设计，才需要开发原型。

什么是"存在风险的设计"？

• 确定的设计（无风险）：如"用MySQL存储订单数据"，技术成熟、无风险 → 无需原型
• 有风险的设计：如"用Redis+Lua脚本实现分布式锁防超卖"，不确定高并发下是否会出现死锁或超卖 → 必须开发原型验证

开发原则：

• 只实现"验证风险所需的最小功能"
  • 示例：验证"分布式锁"的原型，只需模拟"并发请求→抢锁→扣减库存"的核心流程，无需处理"锁超时重试"的细节、无需做前端界面
• 可以简化非核心逻辑，甚至允许有Bug
  • 原因：为了快速验证风险，原型可以简化非核心逻辑，只要能复现风险场景即可
• 只要能复现风险场景、输出验证结果即可
  • 示例：用Python脚本快速搭建，只要能输出验证结果（如"1000并发下无超卖，锁竞争耗时≤50ms"）即可

验证流程

细化架构中的风险点 → 开发极简原型 → 模拟风险场景测试 → 风险验证结论

流程详解：

1. 输入：识别风险点

   • 从细化架构中梳理出"高风险设计项"
   • 明确每个风险点的"验证目标"
   • 示例：风险点"微服务跨服务事务一致性"；验证目标"订单创建与库存扣减必须同时成功或同时失败，无数据不一致"

2. 开发：实现最小功能

   • 围绕验证目标，开发极简原型
   • 示例：验证"跨服务事务"，只需开发"订单服务"和"库存服务"的核心接口，集成Seata等分布式事务框架，无需开发其他服务（如用户服务、支付服务）

3. 测试：模拟风险场景

   • 通过压测、异常测试等手段，复现风险场景
   • 示例：用JMeter模拟"100并发下单"，观察"订单创建成功但库存未扣减"的情况是否出现

4. 输出：风险验证结论

   • 根据测试结果判断风险是否解决
   • 示例：
     • 若解决（无数据不一致）：确认该架构设计可行，进入正式开发
     • 若未解决（仍出现超卖）：分析原因（如锁逻辑有漏洞），优化架构设计后重新开发原型验证，直至风险消除

价值

架构验证不是"纸上谈兵"（靠文档评审判断架构行不行），而是"实战检验"。

什么是"纸上谈兵"？

• 含义：仅通过文档评审、理论分析判断架构是否可行
• 问题：无法发现实际运行中的问题，如高并发下的性能瓶颈、分布式环境下的数据一致性

什么是"实战检验"？

• 含义：通过实际运行架构原型，观察真实场景下的表现
• 优势：能发现理论分析无法发现的问题

什么是"隐性风险"？

• 含义：在架构设计中存在，但通过文档评审难以发现的风险
• 示例：如"分布式锁在高并发下可能出现死锁"、“跨服务事务在异常情况下可能出现数据不一致”

什么是"可观测的测试结果"？

• 含义：通过测试可以量化和验证的结果
• 示例：如"1000并发下无超卖"、“锁竞争耗时≤50ms”、“无数据不一致”

什么是"最小验证载体"？

• 含义：用最少的代码和功能，实现风险验证所需的最小系统
• 原则：只实现验证风险所需的功能，不实现完整系统
• 示例：验证"分布式锁"，只需实现"并发请求→抢锁→扣减库存"的核心流程，无需实现用户管理、商品管理等其他功能

通过架构原型这个"最小验证载体"，把细化架构中的"隐性风险"转化为"可观测的测试结果"，用最低成本、最快速度排查问题。

用小成本避免大风险。若跳过原型验证直接开发，风险爆发后重构成本可能是原型开发的10倍以上。对大型系统而言，这一步至关重要。

 

总结：架构设计流程

需求分析（功能+质量+约束） 
  ↓
领域建模（业务→功能→模型）
  ↓
确定关键需求（功能/质量+约束）
  ↓
概念架构设计（1个决定+4个选择）
  ↓
细化架构设计（5个视图）
  ↓
架构验证（原型开发+风险测试）

核心原则：

1. 需求要追根溯源，有源头有理由
2. 模型为业务服务，非技术主导
3. 关键需求决定架构大方向
4. 概念架构定方向，细化架构落细节
5. 架构验证用小成本避免大风险

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