发帖
雷达卡
文章目录
- 需求分析
- 需求的三个方面
- 需求分析的"两纵三横"框架
- 追根溯源是成败关键
- 领域建模
- 核心原则：业务决定功能，功能决定模型
- 领域建模的输入
- 评审依据：功能支撑能力
- 确定关键需求
- 核心观点：关键需求决定架构大方向
- 关键需求的确定方法
- 架构差异的根源
- 概念架构设计
- 定位：高层架构的战略核心
- 定义：直指关键需求的设计理念与重大抉择
- 细化架构设计
- 核心差异：从"方向"到"细节"
- 设计范畴：5个视角，15个任务
- 输入来源
- 架构验证
- 核心观点：架构原型是验证工具，而非功能演示
- 原型开发的目标：解决风险，而非实现功能
- 验证流程
- 价值
- 总结：架构设计流程
一、需求分析
需求的三个方面
需求必须涵盖功能、质量、约束三个方面，缺一不可。
什么是"功能需求"？
定义：系统要做什么，即系统提供的业务能力
示例：用户登录、订单创建、商品搜索、支付处理
什么是"质量需求"？
定义：系统要做到什么程度，即非功能性的性能指标
示例：性能：响应时间≤200ms、支持10万QPS；可用性：系统可用性≥99.99%；安全性：数据加密、防SQL注入
什么是"约束需求"？
定义：系统开发/落地的限制条件
示例：技术约束：必须使用Java技术栈、必须兼容IE11；合规约束：数据存储需符合GDPR、必须通过等保三级；成本约束：服务器预算不超过100万/年
为什么三个方面缺一不可？
只有功能需求：可能忽略性能、安全等质量要求，导致系统无法实际使用
只有功能+质量：可能忽略技术约束，导致无法落地
只有功能+约束：可能忽略质量需求，导致系统性能不满足业务要求
需求分析的"两纵三横"框架
两纵（贯穿主线的支撑活动）：
需求沟通：持续与需方沟通、启发、验证，避免"闭门造需"（闭门造需风险大）
什么是"闭门造需"？
开发方不跟需方沟通，自己想象需求，导致需求脱离实际业务
为什么危险？
开发的功能用户不用、系统性能不满足实际业务、后期频繁返工
非功能需求确定：质量需求需持续跟进，是持久战，非一次性敲定
为什么是持久战？
质量需求（如性能、可用性）在系统演进过程中会不断变化，需要持续跟进
示例：初期"支持1000并发"即可，业务增长后需要"支持10万并发"，质量需求需要重新确定
三横（需求分析主线）：
确定系统目标：明确系统要解决的核心问题
输出：目标列表（如"提升用户购买转化率30%"、“支撑双11峰值流量”）
研究高层需求：通过"范围+Feature+上下文图"三剑客梳理功能边界
范围框图：定义系统边界，明确系统包含什么、不包含什么
Feature树：将系统目标层级化拆解为核心功能模块与具体功能点（如"用户管理"→"用户注册"、“用户登录”）
上下文图：展示系统与外部系统/用户的交互关系
建立用例模型：将需求转化为可执行的用例图+用例规约
用例图：可视化展示系统功能与参与者的关系
用例规约：详细描述每个用例的前置条件、主流程、异常流程、后置条件
需求跟踪脉络：
系统目标 → 高层需求（范围框图+Feature树+上下文图） → 用例模型（用例图+用例规约）什么是"高飘"到"落地"？
“高飘”：抽象、模糊的需求描述（如"提升用户体验"）
“落地”：具体、可执行的需求描述（如"搜索接口响应时间≤200ms"）
转化过程：需求从抽象的业务目标，逐步细化为可执行的功能规格
需求从"高飘"到"落地"，成果项从"目标列表"到"范围框图+Feature树+上下文图"到"用例图+用例规约"，需求跟踪脉络清晰可辨——每一个细粒度需求，都能追溯到最初的系统目标。
追根溯源是成败关键
常见问题：
把用户随口说的需求当成最终需求，未追问真实场景
接到性能需求未确认是峰值还是日常，未追溯业务目标
后果：
开发的功能用户不用、系统性能不满足实际业务、后期频繁返工
解决方法：追根溯源——确保需求有源头、有理由
什么是"需求源头"？
源头：需求最初产生的业务场景或业务目标
示例：
? 错误：用户说"我要一个搜索功能" → 直接开发搜索功能
? 正确：追问"你用搜索找什么？" → “找商品” → “为什么找商品？” → “想买便宜的商品” →源头：业务目标是"提升用户购买转化率"
什么是"需求理由"？
理由：为什么需要这个需求，它解决了什么业务问题，支撑了什么业务目标
示例：
? 错误：接到需求"系统要支持10万用户同时访问" → 直接设计高并发架构
? 正确：追问"为什么是10万？" → “双11促销预期流量” → “这个数字来自哪里？” → “业务部门基于去年数据预测，目标是提升30%销售额” →理由：支撑业务目标"双11销售额提升30%"
如何建立追溯关系？
通过需求跟踪脉络，建立"细粒度需求 → 用例 → Feature → 高层需求 → 系统目标"的完整链路：
示例追溯链：
系统目标：提升用户购买转化率，支撑30%营收目标
↓
高层需求：用户能快速找到想要的商品
↓
Feature：商品搜索功能
↓
用例：用户搜索商品（用例规约：支持关键词搜索、价格筛选）
↓
细粒度需求：搜索接口响应时间≤200ms（质量需求）验证标准：
当开发质疑"为什么要做这个功能"时，能追溯到系统目标
当需求变更时，能判断是否影响系统目标
当测试发现问题时，能追溯到原始业务场景
二、领域建模
核心原则：业务决定功能，功能决定模型
建模逻辑
业务需求 → 系统功能 → 领域模型什么是"业务决定功能"？
含义：所有系统功能均源自业务需求，而非技术人员的设想。
示例：
- 错误：开发方认为“应添加取消按钮” → 设计订单取消功能
- 正确：业务场景“用户支付超时/不愿购买” → 需要订单取消功能 → 设计订单取消功能
什么是"功能决定模型"？
含义：领域模型是实现功能的业务抽象载体，功能所需的业务逻辑决定了模型的概念、行为与关系。
示例：
功能：订单取消
模型设计：
- 订单实体需具备“订单状态”属性（用于判断是否可取消）
- 订单实体需具备“cancelOrder()”行为（用于执行取消逻辑）
- 订单实体与商品实体需具备“库存关联关系”（取消后恢复库存）
关键要点：模型不仅是技术层面的抽象，而是由“业务与功能”驱动的业务本质映射。
什么是"业务本质映射"？
模型反映的是业务领域的核心概念和规则，而非技术实现细节。
示例：订单模型反映的是“订单有状态、可取消、关联商品”等业务规则，而非“订单使用MySQL存储”等技术细节。
模型必须支持当前功能，并为未来功能扩展留出空间。模型服务于业务，而非技术主导模型。
含义：模型设计的起点是业务需求，而非技术框架或设计模式。
反例：为了“采用聚合根模式”而强制拆分实体，导致模型复杂化但业务价值不大。
脱离业务功能的模型是“无源之水”，无法支持实际业务。
“无源之水”的含义：没有业务根源的模型，如同没有水源的河流，无法持续。
后果：模型无法支持实际业务，最终需要重构。
领域建模的输入
现在的功能：（来自《软件需求规格说明书》）
模型必须能够直接支持当前已明确的所有业务功能。
例：需求中有“订单拆分”，模型必须设计“订单实体”与“子订单实体”的组合关系。
未来的功能：（可扩展性要求）
模型要预留扩展点，避免未来功能迭代时需推倒重构。
例：未来支持多种订单类型，建模时用“泛化关系”设计“订单父类+各类型订单子类”。
可扩展性设计思想：泛化、值对象、引入等设计模式，为未来功能预留空间。
评审依据：功能支撑能力
评审不能仅凭“技术优美度”（如“模型是否简洁”“使用了多少DDD核心概念”），而应回归“功能支撑能力”。
当前功能能否支撑？
方法：用已明确的功能反推模型，检查是否有遗漏。
示例：“申请退款”功能需要：
- 订单实体是否有“已支付”状态判断？→ 检查模型
- 退款申请实体是否关联了“订单ID”“退款金额”等必要属性？→ 检查模型
若有遗漏，模型需优化。
未来功能能否扩展？
方法：用可扩展性要求验证模型，检查结构是否固化。
示例：“未来要增加会员专属订单折扣”需要：
- 订单实体是否能关联“用户会员等级”？→ 检查模型
- 是否有“计算折扣金额”的扩展行为（或预留接口）？→ 检查模型
若模型结构固化、无法新增关联，则为不合格。
确定关键需求
核心观点：关键需求决定架构大方向。
重要前提：在架构设计中，所有需求并非一律平等。
为什么需求不能一律平等？
不同需求对架构的影响程度差异巨大。
- 某些需求是“基础但不影响方向”的（如“用户修改昵称”），可通过常规设计实现，不会改变架构核心逻辑。
- 某些需求是“牵一发而动全身”的（如“双11峰值支持10万QPS”），若不优先满足，后续架构再优化也无法支撑系统实施。
什么是“关键需求”？
定义：对架构影响最大、决定架构“大方向”的需求（包括关键功能和关键质量）。
特点：若不优先满足，后续架构再优化也无法支撑系统实施。
架构设计不是“满足所有需求”，而是“用有限资源解决核心问题”。
什么是“分水岭”？
含义：关键需求的确定步骤，是架构设计过程中“决定架构差异”的关键节点。
作用：在此步骤前，所有系统看起来“差不多”；在此步骤后，不同系统的架构开始分化（大系统与小系统、A平台与B平台）。
为什么是分水岭？
关键需求不同，架构方向也不同；关键需求相同，架构方向可能相似。
关键需求的确定步骤是架构设计的“分水岭”，决定了架构的大方向。
关键需求的确定方法
关键功能 = 功能需求 + 约束需求（交叉分析）
关键质量 = 质量需求 + 约束需求（交叉分析）
什么是“交叉分析”？
含义：将功能/质量需求与约束需求进行组合分析，判断是否成为关键需求。
方法：对每个功能/质量需求，结合约束需求，评估其对架构的影响程度。
示例：
功能需求“用户登录” + 约束“支持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个核心模块；定义“创建订单接口（入参：商品ID、数量；出参：订单号）” | 明确系统功能单元组成与协作，指导开发团队的模块分工 |
| 数据架构视角 | 数据库选型、表结构设计、分片策略、缓存策略 | 选型MySQL/Redis；设计订单表结构（订单号、金额、状态等字段）；Redis缓存订单数据 | 确保数据存储高效、安全、可扩展，支持业务数据的读写需求 |
| 开发架构视角 | 技术栈细化、代码目录规范、构建流程 | 微服务使用Spring Cloud Alibaba；接口采用OpenAPI规范；定义代码目录结构 | 统一开发标准，确保团队编码风格一致、技术选型可行 |
| 运行架构视角 | 服务部署拓扑、负载均衡、熔断降级 | 订单服务部署3个节点；Nginx轮询负载均衡；配置熔断降级策略 | 保障系统运行时的性能与可用性，例如通过多节点部署应对高并发 |
| 物理架构视角 | 服务器规格、网络拓扑、存储设备选型 | 服务器8核16G；内外网隔离；SSD用于数据库 | 衔接技术设计与硬件资源，确保架构在实际物理环境中可部署 |
细化架构设计的输入既来源于“需求成果”层面，也来源于“高层架构”层面。
“需求成果层面”是指需求分析阶段生成的所有需求文档和模型，包括功能需求、质量需求、约束需求、用例模型等，其目的是确保细化架构覆盖所有需求，每个需求都有技术载体。
“高层架构层面”是指概念架构设计阶段产生的顶层决策，包括子系统划分、架构风格选型、技术选型等，其目的是确保细化架构在概念架构的框架下进行，不偏离顶层决策。
需求成果：所有需求（细化架构要为“需求”而设计，需覆盖所有需求，而非仅关键需求）
关键对比：概念架构设计的输入是“关键需求”，细化架构的输入是“所有需求”
概念架构：必须遵循概念架构的顶层决策（细化架构要在“概念架构”的设计思想下进行）
约束关系：细化架构是概念架构的“落地执行者”，不能违背概念架构的决策
领域模型对逻辑架构视图的影响：领域模型设计——实体转化为模块，关系转化为依赖
示例：领域模型中的“订单实体”转化为逻辑架构中的“订单模块”
领域模型对数据架构视图的影响：存储格式设计——实体属性决定表结构，聚合关系影响存储策略
示例：订单实体的“订单号、金额、状态”等属性决定订单表的字段设计
架构验证
核心观点：架构原型是验证工具，而非功能演示。
架构验证的输出成果是“架构原型”。与常规开发不同，架构原型的开发不是为了完美地、无错误地实现功能，而是在“细化架构”的总体指导下，提前开发出存在“风险”的设计部分，然后通过测试等手段判断这些“风险”是否得到解决。
架构原型 vs 功能演示：
- 功能演示：展示“系统能做什么”，追求功能完整性；
- 架构原型：验证“架构设计是否可行”，只关注有风险的设计。
原型开发的目标：解决风险，而非实现功能。
筛选标准：只有存在不确定性、可能使架构失败的设计，才需要开发原型。
什么是“存在风险的设计”？
- 确定的设计（无风险）：如“用MySQL存储订单数据”，技术成熟、无风险 → 无需原型；
- 有风险的设计：如“用Redis+Lua脚本实现分布式锁防超卖”，不确定高并发下是否会出现死锁或超卖 → 必须开发原型验证。
开发原则：只实现“验证风险所需的最小功能”。
示例：验证“分布式锁”的原型，只需模拟“并发请求→抢锁→扣减库存”的核心流程，无需处理“锁超时重试”的细节、无需做前端界面。
可以简化非核心逻辑，甚至允许有Bug。
原因：为了快速验证风险，原型可以简化非核心逻辑，只要能复现风险场景即可。
只要能复现风险场景、输出验证结果即可。
示例：用Python脚本快速搭建，只要能输出验证结果（如“1000并发下无超卖，锁竞争耗时≤50ms”）即可。
验证流程
细化架构中的风险点 → 开发极简原型 → 模拟风险场景测试 → 风险验证结论流程详解：
输入：识别风险点
从细化架构中梳理出“高风险设计项”，明确每个风险点的“验证目标”。
示例
风险点“微服务跨服务事务一致性”；验证目标“订单创建与库存扣减必须同时成功或同时失败，无数据不一致”
开发：实现基础功能
围绕验证目标，开发简易原型
示例
：验证“跨服务事务”，只需开发“订单服务”和“库存服务”的主要接口，集成Seata等分布式事务框架，无需开发其他服务（如用户服务、支付服务）
测试：模拟风险情境
通过压力测试、异常测试等方法，重现风险情境
示例
：使用JMeter模拟“100并发下单”，检查“订单创建成功但库存未扣减”的情况是否发生
输出：风险验证结论
根据测试结果判断风险是否得到解决
示例
：如果解决（无数据不一致）：确认该架构设计合理，进入正式开发
：如果未解决（仍然出现超卖）：分析原因（如锁定逻辑有漏洞），优化架构设计后重新开发原型验证，直到风险消除
价值
架构验证不仅是“纸上谈兵”
（依靠文档评审判断架构是否可行），而是“实战检验”。
什么是“纸上谈兵”？
含义
：仅通过文档评审、理论分析判断架构是否合理
问题
：无法识别实际运行中的问题，如高并发下的性能瓶颈、分布式环境下的数据一致性
什么是“实战检验”？
含义
：通过实际运行架构原型，观察真实场景下的表现
优势
：能够发现理论分析无法识别的问题
什么是“隐性风险”？
含义
：在架构设计中存在的，但通过文档评审难以发现的风险
示例
：如“分布式锁在高并发下可能出现死锁”、“跨服务事务在异常情况下可能出现数据不一致”
什么是“可观测的测试结果”？
含义
：通过测试可以量化的结果
示例
：如“1000并发下无超卖”、“锁竞争耗时≤50ms”、“无数据不一致”
什么是“最小验证载体”？
含义
：用最少的代码和功能，实现风险验证所需的最小系统
原则
：只实现验证风险所需的功能，不实现完整系统
示例
：验证“分布式锁”，只需实现“并发请求→抢锁→扣减库存”的核心流程，无需实现用户管理、商品管理等其他功能
通过架构原型这个“最小验证载体”，将细化架构中的“隐性风险”转化为“可观测的测试结果”，用最低成本、最快速度排查问题。
用小成本避免大风险。若跳过原型验证直接开发，风险爆发后重构成本可能是原型开发的10倍以上。对于大型系统而言，这一步至关重要。
总结：架构设计流程
需求分析（功能+质量+约束）
↓
领域建模（业务→功能→模型）
↓
确定关键需求（功能/质量+约束）
↓
概念架构设计（1个决定+4个选择）
↓
细化架构设计（5个视图）
↓
架构验证（原型开发+风险测试）核心原则
：需求要追根溯源，有依据有理由
模型服务于业务，非技术主导
关键需求决定架构大方向
概念架构定方向，细化架构落细节
架构验证用小成本避免大风险
参考：《软件架构设计》–温昱
京公网安备 11010802022788号
