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

文章目录一、需求分析需求的三个方面需求分析的两纵三横框架追根溯源是成败关键二、领域建模核心原则业务决定功能功能决定模型领域建模的输入评审依据功能支撑能力三、确定关键需求核心观点关键需求决定架构大方向关键需求的确定方法架构差异的根源四、概念架构设计定位高层架构的战略核心定义直指关键需求的设计思想与重大选择五、细化架构设计核心差异从方向到细节设计范畴5个视图15个任务输入来源六、架构验证核心观点架构原型是验证工具非功能Demo原型开发的目标解决风险非实现功能验证流程价值总结架构设计流程一、需求分析需求的三个方面需求必须涵盖功能、质量、约束三个方面缺一不可。什么是功能需求定义系统要做什么即系统提供的业务能力示例用户登录、订单创建、商品搜索、支付处理什么是质量需求定义系统要做到什么程度即非功能性的性能指标示例性能响应时间≤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若不优先满足后续架构再优化也无法支撑系统落地什么是关键需求定义对架构影响最大、决定架构大方向的需求含关键功能、关键质量特点若不优先满足后续架构再优化也无法支撑系统落地架构设计不是满足所有需求而是用有限资源解决核心问题。什么是分水岭含义关键需求的确定这一步是架构设计过程中决定架构差异的关键节点作用在这一步之前所有系统看起来差不多在这一步之后不同系统的架构开始分化大系统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用于数据库衔接技术设计与硬件资源确保架构在实际物理环境中可部署输入来源细化架构设计的输入既来自需求成果层面、也来自高层架构层面。什么是需求成果层面含义需求分析阶段产生的所有需求文档和模型包含功能需求、质量需求、约束需求、用例模型等作用细化架构必须覆盖所有需求确保每个需求都有技术载体什么是高层架构层面含义概念架构设计阶段产生的顶层决策包含子系统划分、架构风格选型、技术选型等作用细化架构必须在概念架构的框架下进行不能偏离顶层决策需求成果所有需求细化架构要为需求而设计需覆盖所有需求而非仅关键需求关键对比概念架构设计的输入是关键需求细化架构的输入是所有需求概念架构必须遵循概念架构的顶层决策细化架构要在概念架构的设计思想下进行约束关系细化架构是概念架构的落地执行者不能违背概念架构的决策领域模型影响逻辑架构视图领域模型设计——实体转化为模块关系转化为依赖示例领域模型中的订单实体转化为逻辑架构中的订单模块影响数据架构视图存储格式设计——实体属性决定表结构聚合关系影响存储策略示例订单实体的订单号、金额、状态等属性决定订单表的字段设计六、架构验证核心观点架构原型是验证工具非功能Demo架构验证的输出成果是架构原型。和一般的开发不同架构原型的开发不是要完美地、无Bug地实现功能而是在细化架构的总体指导下仅把存在风险的那些设计尽早开发出来然后通过执行测试等手段判断风险是否解决。架构原型vs功能Demo功能Demo展示系统能做什么追求功能完整架构原型验证架构设计行不行只聚焦有风险的设计原型开发的目标解决风险非实现功能筛选标准只有存在不确定性、可能导致架构失败的设计才需要开发原型。什么是存在风险的设计确定的设计无风险如用MySQL存储订单数据技术成熟、无风险 → 无需原型有风险的设计如用RedisLua脚本实现分布式锁防超卖不确定高并发下是否会出现死锁或超卖 → 必须开发原型验证开发原则只实现验证风险所需的最小功能示例验证分布式锁的原型只需模拟并发请求→抢锁→扣减库存的核心流程无需处理锁超时重试的细节、无需做前端界面可以简化非核心逻辑甚至允许有Bug原因为了快速验证风险原型可以简化非核心逻辑只要能复现风险场景即可只要能复现风险场景、输出验证结果即可示例用Python脚本快速搭建只要能输出验证结果如1000并发下无超卖锁竞争耗时≤50ms即可验证流程细化架构中的风险点 → 开发极简原型 → 模拟风险场景测试 → 风险验证结论流程详解输入识别风险点从细化架构中梳理出高风险设计项明确每个风险点的验证目标示例风险点微服务跨服务事务一致性验证目标订单创建与库存扣减必须同时成功或同时失败无数据不一致开发实现最小功能围绕验证目标开发极简原型示例验证跨服务事务只需开发订单服务和库存服务的核心接口集成Seata等分布式事务框架无需开发其他服务如用户服务、支付服务测试模拟风险场景通过压测、异常测试等手段复现风险场景示例用JMeter模拟100并发下单观察订单创建成功但库存未扣减的情况是否出现输出风险验证结论根据测试结果判断风险是否解决示例若解决无数据不一致确认该架构设计可行进入正式开发若未解决仍出现超卖分析原因如锁逻辑有漏洞优化架构设计后重新开发原型验证直至风险消除价值架构验证不是纸上谈兵靠文档评审判断架构行不行而是实战检验。什么是纸上谈兵含义仅通过文档评审、理论分析判断架构是否可行问题无法发现实际运行中的问题如高并发下的性能瓶颈、分布式环境下的数据一致性什么是实战检验含义通过实际运行架构原型观察真实场景下的表现优势能发现理论分析无法发现的问题什么是隐性风险含义在架构设计中存在但通过文档评审难以发现的风险示例如分布式锁在高并发下可能出现死锁、“跨服务事务在异常情况下可能出现数据不一致”什么是可观测的测试结果含义通过测试可以量化和验证的结果示例如1000并发下无超卖、“锁竞争耗时≤50ms”、“无数据不一致”什么是最小验证载体含义用最少的代码和功能实现风险验证所需的最小系统原则只实现验证风险所需的功能不实现完整系统示例验证分布式锁只需实现并发请求→抢锁→扣减库存的核心流程无需实现用户管理、商品管理等其他功能通过架构原型这个最小验证载体把细化架构中的隐性风险转化为可观测的测试结果用最低成本、最快速度排查问题。用小成本避免大风险。若跳过原型验证直接开发风险爆发后重构成本可能是原型开发的10倍以上。对大型系统而言这一步至关重要。总结架构设计流程需求分析功能质量约束 ↓ 领域建模业务→功能→模型 ↓ 确定关键需求功能/质量约束 ↓ 概念架构设计1个决定4个选择 ↓ 细化架构设计5个视图 ↓ 架构验证原型开发风险测试核心原则需求要追根溯源有源头有理由模型为业务服务非技术主导关键需求决定架构大方向概念架构定方向细化架构落细节架构验证用小成本避免大风险参考《软件架构设计》–温昱