【软件架构设计方法论（9）】关键需求：如何从海量需求中找出决定架构的那20%

关键需求是架构设计的"指南针"——从海量需求中快速识别真正决定架构的那20%，避免"走错方向"的致命错误，让架构设计在有限时间内聚焦核心问题。正如温昱在《一线架构师实践指南》中所说："关键需求决定架构，其余需求验证架构。"本文通过关键质量、关键功能、关键约束三个核心维度和电商系统实战案例，帮你掌握"知其所以然"的关键需求确定方法，避免在需求分析阶段迷失方向。

 

核心知识点：连续论证"是什么-为什么-怎么选"

知识点1：关键质量——权衡相互制约的质量属性

通俗理解：关键质量就像"买车时的取舍"——想要"省油"和"动力强"往往矛盾，必须选一个作为主要目标，另一个作为次要目标。架构设计也是如此，不同质量属性（如性能vs可维护性、安全性vs互操作性）往往相互制约，架构师必须明确优先级，否则架构设计会左右为难。

核心作用：关键质量通过**“权衡相互制约的关系”**，帮助架构师在多个质量要求中确定主要目标和次要目标，从而指导架构选型和技术决策。这解决了业务痛点"多个质量要求相互矛盾，不知道优先满足哪个"。

深入论证：为什么需要权衡质量属性？这背后解决的是什么业务问题？

业务痛点1：多个质量要求相互矛盾，架构设计左右为难

想象一个电商系统：需求文档中同时要求"高性能（支持1万并发）"、“高可用（99.9%可用性）”、“高安全性”、“易维护”、“低成本”。如果架构师试图同时满足所有要求，会出现什么问题？

• 问题1：技术选型困难：追求极致性能可能用底层技术（如C++），但可维护性差；追求高可用需要冗余（如多机房部署），但成本增加；追求高安全性需要加密、认证，但会增加性能开销。如果试图同时满足所有要求，会导致技术选型困难，不知道选什么技术。
• 问题2：架构设计混乱：如果所有质量要求都同等重要，架构设计会变得混乱——既要考虑性能，又要考虑可维护性，又要考虑成本，导致架构设计没有重点，无法聚焦核心问题。
• 问题3：资源浪费：如果试图同时满足所有要求，会导致资源浪费——在非关键质量上投入过多资源，在关键质量上投入不足，最终导致系统既没有高性能，也没有高可用，更没有低成本。

解决方案：权衡质量属性，确定主要目标和次要目标

关键质量的核心思想是：不同质量属性往往相互制约，架构师必须通过权衡，确定哪个是主要目标，哪个是次要目标，然后围绕主要目标设计架构，次要目标在满足主要目标的前提下兼顾。这就像买车，如果主要目标是"省油"，就选择混合动力车；如果主要目标是"动力强"，就选择跑车；不能既要省油又要动力强，必须做出取舍。

这样设计解决了什么业务问题？

• 指导技术选型：一旦确定了主要目标（如性能），就可以围绕性能选择技术栈（如Redis缓存、异步处理），（todo：get）避免技术选型困难。 这解决了业务痛点"多个质量要求相互矛盾，不知道优先满足哪个"。
• 聚焦架构设计：围绕主要目标设计架构，次要目标在满足主要目标的前提下兼顾，避免架构设计混乱。例如，如果性能是主要目标，就设计缓存架构、异步处理；如果可维护性是主要目标，就选择成熟的框架（如Spring Boot），而不是底层技术。
• 优化资源分配：在关键质量上投入更多资源，在非关键质量上投入较少资源，避免资源浪费。例如，如果性能是主要目标，就在缓存、数据库优化上投入更多资源；如果可维护性是主要目标，就在代码规范、文档上投入更多资源。

质量属性相互制约的常见关系：

• 性能 vs 可维护性：追求极致性能可能用底层技术（如C++、汇编），但可维护性差；追求可维护性可能用高级框架（如Spring Boot），但性能可能不如底层技术。
• 安全性 vs 性能：加密、认证会增加性能开销；追求性能可能减少安全检查，但安全性降低。
• 可用性 vs 成本：高可用需要冗余（如多机房部署、主备切换），成本增加；降低成本可能减少冗余，但可用性降低。
• 互操作性 vs 安全性：支持多种协议、多种系统集成（互操作性）可能增加安全风险；追求安全性可能限制系统集成，但互操作性降低。

决策逻辑：什么时候需要权衡质量属性？

• 需要权衡的场景：系统有多个质量要求，且这些要求可能相互矛盾（如性能vs可维护性、安全性vs互操作性）。例如，电商系统同时要求高性能、高可用、高安全性，需要权衡。
• 不需要权衡的场景：系统只有一个主要质量要求，或者多个质量要求不矛盾。例如，简单的内部管理系统，主要要求是易用性，不需要权衡。

判断标准：

• 主要目标：对业务影响最大、失败后果最严重的质量属性。例如，电商系统的性能直接影响用户体验和转化率，性能是主要目标。
• 次要目标：必须兼顾，但不能影响主要目标的质量属性。例如，电商系统的可维护性、安全性必须兼顾，但不能影响性能。

知识点2：关键功能——通过4条启发规则识别核心功能

通俗理解：关键功能就像"盖房子时的核心房间"——不需要把所有房间都画在施工图上，只需要画出最重要的几个（客厅、卧室、厨房），其他房间可以后期补充。架构设计也是如此，功能需求很多时，不需要全部分析，只需要分析20-30%的关键功能，就能设计出合适的架构。

核心作用：关键功能通过**“4条启发规则（核心功能、必做功能、高风险功能、独特功能）”**，帮助架构师从海量功能需求中识别出真正决定架构的那20%，从而发现系统需要哪些模块，以及模块如何协作。这解决了业务痛点"功能需求太多，不知道分析哪些"。

深入论证：为什么只需要分析20-30%的关键功能？这背后解决的是什么业务问题？

业务痛点1：功能需求太多，分析成本高、时间紧

想象一个电商系统：需求文档中有50+个功能点（商品管理、订单管理、支付、用户管理、商品搜索、商品推荐、优惠券、积分、评价、物流跟踪等）。如果架构师试图分析所有功能，会出现什么问题？

• 问题1：分析成本高：分析50+个功能点需要大量时间，可能花费数周甚至数月，但架构设计时间有限（通常只有1-2周），无法完成所有分析。
• 问题2：分析深度不够：如果试图分析所有功能，每个功能的分析深度会不够，无法发现系统需要哪些模块、模块如何协作，导致架构设计不充分。
• 问题3：无法聚焦核心问题：如果所有功能都同等重要，架构设计会无法聚焦核心问题，导致架构设计没有重点，无法解决关键业务问题。

解决方案：通过4条启发规则识别关键功能

关键功能的核心思想是：通过分析少数关键功能（核心功能、必做功能、高风险功能、独特功能），发现系统需要哪些模块，以及模块如何协作，其他功能可以基于这些模块扩展。这就像盖房子，先确定核心房间（客厅、卧室、厨房），其他房间（书房、阳台）可以基于核心房间扩展。

这样设计解决了什么业务问题？

• 降低分析成本：只需要分析20-30%的关键功能，大大降低分析成本，在有限时间内完成架构设计。这解决了业务痛点"功能需求太多，分析成本高、时间紧"。
• 提高分析深度：聚焦关键功能，可以深入分析每个功能涉及的模块、模块如何协作，发现系统需要哪些模块。例如，通过分析"用户下单"功能，可以发现系统需要订单模块、库存模块、支付模块等。
• 聚焦核心问题：通过识别关键功能，可以聚焦核心业务问题，围绕关键功能设计架构，其他功能可以基于这些模块扩展。例如，如果"商品搜索"是关键功能，就设计搜索服务模块；如果"商品推荐"是关键功能，就设计推荐服务模块。

4条启发规则详解：

规则1：核心功能——业务层接口中体现的功能

本质原理：核心功能是涉及多个模块协作的功能，通过分析核心功能，可以发现系统需要哪些模块，以及模块如何协作。这就像"拼图游戏"——通过分析核心功能，可以发现系统需要哪些"拼图块"（模块），以及"拼图块"如何拼接（模块如何协作）。

为什么这样设计：

• 解决业务痛点"不知道系统需要哪些模块"：如果不知道系统需要哪些模块，就无法设计架构。通过分析核心功能（如"用户下单"涉及用户模块、商品模块、订单模块、库存模块、支付模块的协作），可以发现系统需要哪些模块。
• 发现模块协作关系：核心功能涉及多个模块协作，通过分析核心功能，可以发现模块之间的协作关系（如订单模块调用库存模块、支付模块），从而设计模块接口。

决策逻辑：

• 识别方法：看业务层接口，哪些功能涉及多个模块协作？涉及模块越多，越可能是核心功能。
• 判断标准：涉及3个以上模块协作的功能，通常是核心功能。例如，"用户下单"涉及5个模块协作，是核心功能。

规则2：必做功能——监管要求或核心业务特性

本质原理：必做功能是"必须做的"功能，不做系统无法上线或无法使用。通过识别必做功能，可以发现系统必须支持的功能，从而在架构中预留或优先实现。

为什么这样设计：

• 解决业务痛点"遗漏关键功能"：如果遗漏了必做功能（如支付功能、退款功能），系统无法上线或无法使用，导致项目失败。通过识别必做功能，可以确保系统必须支持的功能不被遗漏。
• 指导架构设计：必做功能必须在架构中预留或优先实现。例如，如果"支付功能"是必做功能，就必须在架构中设计支付集成层；如果"订单退款"是必做功能，就必须在架构中设计退款处理模块。

决策逻辑：

• 识别方法：看需求文档，哪些功能是"必须做的"，不做系统无法上线？监管要求、核心业务特性通常是必做功能。
• 判断标准：不做系统无法上线或无法使用的功能，通常是必做功能。例如，"支付功能"是电商系统的核心业务特性，不做系统无法使用；"订单退款"是监管要求，不做无法通过监管审查。

规则3：高风险功能——性能要求高、技术难度大

本质原理：高风险功能是性能要求高、技术难度大、失败影响大的功能。通过识别高风险功能，可以进行针对性的架构设计，避免性能瓶颈或技术风险。

为什么这样设计：

• 解决业务痛点"性能瓶颈或技术风险"：如果高风险功能（如商品搜索）的架构设计不合理，会导致性能瓶颈（搜索慢）或技术风险（无法满足性能要求），直接影响业务。通过识别高风险功能，可以进行针对性的架构设计（如引入Elasticsearch），避免性能瓶颈或技术风险。
• 指导技术选型：高风险功能通常需要特殊的技术选型。例如，如果"商品搜索"是高风险功能（性能要求极高），就需要引入全文搜索引擎（如Elasticsearch），而不是数据库LIKE查询。

决策逻辑：

• 识别方法：看需求文档，哪些功能性能要求高、技术难度大、失败影响大？性能要求高（如响应时间<1秒）、技术难度大（如需要全文搜索引擎）、失败影响大（如搜索慢会导致用户流失）的功能，通常是高风险功能。
• 判断标准：同时满足"性能要求高"、“技术难度大”、"失败影响大"三个条件的功能，通常是高风险功能。例如，"商品搜索"性能要求极高（响应时间<1秒，支持高并发），技术难度大（需要全文搜索引擎），失败影响大（搜索慢会导致用户流失），是高风险功能。

规则4：独特功能——特殊的技术需求

本质原理：独特功能是涉及特殊技术需求的功能，其他功能没有涉及。通过识别独特功能，可以在架构中预留特殊技术需求，避免后续扩展困难。

为什么这样设计：

• 解决业务痛点"后续扩展困难"：如果独特功能（如商品推荐需要机器学习算法）的架构设计不合理，会导致后续扩展困难（无法接入推荐算法）。通过识别独特功能，可以在架构中预留特殊技术需求（如预留机器学习接口），避免后续扩展困难。
• 指导架构设计：独特功能通常需要独立的服务模块。例如，如果"商品推荐"是独特功能（需要机器学习算法），就需要设计独立的推荐服务模块，而不是混在其他模块中。

决策逻辑：

• 识别方法：看需求文档，哪些功能涉及特殊的技术需求，其他功能没有涉及？涉及机器学习、大数据、区块链等特殊技术的功能，通常是独特功能。
• 判断标准：涉及其他功能没有涉及的特殊技术需求的功能，通常是独特功能。例如，"商品推荐"需要机器学习算法（协同过滤、内容推荐），其他功能（如商品管理、订单管理）主要是CRUD操作，不需要机器学习，所以"商品推荐"是独特功能。

知识点3：关键约束——转化为功能或质量需求

通俗理解：关键约束就像"做菜时的食材限制"——(todo:get)"预算有限"这个约束，不是直接写在菜谱里，而是转化为"选择便宜的食材"这个具体决策。架构设计也是如此，约束（如预算、时间、遗留系统）不能直接指导架构设计，必须转化为功能需求或质量需求，才能影响架构。

核心作用：关键约束通过 “转化为功能或质量需求” ， 帮助架构师将抽象的约束（如预算有限、时间紧迫）转化为可执行的技术决策（如选择开源技术栈、购买第三方服务），从而指导架构选型和技术决策。这解决了业务痛点"约束无法直接指导架构设计"。

深入论证：为什么约束必须转化为需求？这背后解决的是什么业务问题？

业务痛点1：约束无法直接指导架构设计

想象一个电商系统：项目有明确的约束（预算50万、3个月上线、团队5人）。如果架构师试图直接用这些约束指导架构设计，会出现什么问题？

• 问题1：约束太抽象：约束（如"预算50万"）太抽象，无法直接指导架构设计。架构师不知道"预算50万"意味着什么——是选择开源技术栈，还是购买商业软件？是选择云服务，还是自建服务器？
• 问题2：约束相互矛盾：多个约束可能相互矛盾。例如，"预算50万"和"3个月上线"可能矛盾——如果选择便宜的技术栈，可能需要更长的开发时间；如果选择快速开发的技术栈，可能需要更高的成本。
• 问题3：无法权衡：如果约束无法转化为需求，就无法与其他需求（如关键质量、关键功能）权衡，导致架构设计无法综合考虑所有因素。

解决方案：将约束转化为功能或质量需求

关键约束的核心思想是：约束（如预算、时间、遗留系统）不能直接指导架构设计，必须转化为功能需求或质量需求，才能影响架构。这就像做菜，"预算有限"这个约束，不是直接写在菜谱里，而是转化为"选择便宜的食材"这个具体决策。

这样设计解决了什么业务问题？

• 指导技术选型：一旦将约束转化为需求，就可以指导技术选型。例如，如果"预算有限"转化为"选择开源技术栈"，就可以选择Spring Boot、MySQL、Redis等开源技术，而不是购买商业软件。这解决了业务痛点"约束无法直接指导架构设计"。
• 支持权衡：将约束转化为需求后，可以与其他需求（如关键质量、关键功能）权衡，综合考虑所有因素。例如，如果"时间紧迫"转化为"购买第三方服务"，就可以与"性能要求"权衡——购买第三方支付服务，既节省开发时间，又满足性能要求。
• 明确决策依据：将约束转化为需求后，可以明确决策依据。例如，如果"团队规模小"转化为"选择团队熟悉的技术栈"，就可以明确选择Java而不是Go、Rust等新技术，因为团队不熟悉，学习成本高。

约束转化的常见方式：

• 预算约束 → 质量需求：预算有限 → 选择开源技术栈（Spring Boot、MySQL、Redis），不购买商业软件；预算充足 → 选择商业软件或云服务。
• 时间约束 → 功能需求：时间紧迫 → 购买第三方服务（如支付、短信），不自己开发；时间充足 → 自己开发，降低成本。
• 团队约束 → 质量需求：团队规模小 → 选择团队熟悉的技术栈（Java），不选择新技术；团队规模大 → 可以选择新技术，提高技术水平。
• 遗留系统约束 → 功能需求：必须与遗留系统集成 → 设计集成层（支持REST、SOAP、消息队列），不设计独立系统。

决策逻辑：什么时候需要转化约束？

• 需要转化的场景：项目有明确的约束（如预算、时间、遗留系统），且这些约束可能影响架构设计。例如，预算50万、3个月上线、团队5人，这些约束都会影响架构设计，需要转化。
• 不需要转化的场景：约束不影响架构设计，或者约束已经隐含在需求中。例如，如果需求中已经明确要求"使用Java技术栈"，就不需要将"团队熟悉Java"这个约束转化为需求。

判断标准：

• 影响架构设计：如果约束可能影响架构设计（如技术选型、架构风格），就需要转化。例如，"预算50万"可能影响技术选型（选择开源还是商业软件），需要转化。
• 可以转化为需求：如果约束可以转化为功能需求或质量需求，就需要转化。例如，"时间紧迫"可以转化为"购买第三方服务"这个功能需求。

 

实战场景串联:电商系统的关键需求确定——从业务痛点到架构落地

业务背景：某创业公司需要开发电商系统，支持用户浏览商品、下单、支付。需求文档中有50+个功能点（商品管理、订单管理、支付、用户管理、商品搜索、商品推荐等），质量需求包括高性能（支持1万并发）、高可用（99.9%可用性）、安全性，约束包括预算50万、3个月上线、团队5人。

业务痛点识别：

痛点1：需求太多，不知道分析哪些

• 需求文档中有50+个功能点，如果全部分析，需要数周甚至数月，但架构设计时间有限（只有1周），无法完成所有分析。
• 如果试图分析所有功能，每个功能的分析深度会不够，无法发现系统需要哪些模块、模块如何协作，导致架构设计不充分。

痛点2：多个质量要求相互矛盾，不知道优先满足哪个

• 需求文档中同时要求"高性能（支持1万并发）"、“高可用（99.9%可用性）”、“高安全性”、“易维护”、“低成本”。
• 如果试图同时满足所有要求，会导致技术选型困难、架构设计混乱、资源浪费。

痛点3：约束无法直接指导架构设计

• 项目有明确的约束（预算50万、3个月上线、团队5人），但这些约束太抽象，无法直接指导架构设计。
• 如果约束无法转化为需求，就无法与其他需求权衡，导致架构设计无法综合考虑所有因素。

技术挑战：如何在1周内确定关键需求，设计出合适的架构？需要哪些模块？如何选型技术栈？如何确保架构能够支持系统的长期演进？

解决方案：用关键需求方法解决业务痛点

第一步：确定关键质量——权衡相互制约的关系

核心思路：通过权衡质量属性，确定主要目标和次要目标，从而指导技术选型和架构设计。这解决了业务痛点"多个质量要求相互矛盾，不知道优先满足哪个"。

识别质量需求：

• 性能：支持1万并发，响应时间<1秒
• 可用性：99.9%可用性，支持故障自动恢复
• 安全性：数据加密、用户认证、支付安全
• 可维护性：代码规范、文档完善、易于扩展
• 成本：预算50万，尽量降低成本

识别相互制约的关系：

• 性能 vs 可维护性：追求极致性能可能用底层技术（如C++），但可维护性差；追求可维护性可能用高级框架（如Spring Boot），但性能可能不如底层技术。
• 安全性 vs 性能：加密、认证会增加性能开销；追求性能可能减少安全检查，但安全性降低。
• 可用性 vs 成本：高可用需要冗余（如多机房部署、主备切换），成本增加；降低成本可能减少冗余，但可用性降低。

确定主要目标和次要目标：

• 主要目标：性能（支持1万并发）—— 电商系统，性能直接影响用户体验和转化率。如果性能不达标，用户会流失，业务会失败。
• 次要目标：可维护性、安全性—— 必须兼顾，但不能影响性能。例如，使用HTTPS、数据加密，但不影响性能；选择成熟的Spring Boot框架，而不是底层技术。

为什么这样设计：

• 解决业务痛点"多个质量要求相互矛盾"：通过权衡，确定性能是主要目标，可维护性、安全性是次要目标，从而指导技术选型——选择高性能技术栈（Redis缓存、异步处理），同时兼顾可维护性（Spring Boot框架）、安全性（HTTPS、数据加密）。
• 业务价值：如果性能不达标，用户会流失，业务会失败。因此，性能是主要目标，其他质量属性在满足性能的前提下兼顾。这确保了系统能够满足业务需求，同时兼顾其他质量属性。

架构决策：

• 选择高性能技术栈：Java + Spring Boot + Redis + MySQL（Spring Boot兼顾可维护性，Redis提升性能，MySQL稳定可靠）
• 设计缓存架构：Redis缓存热点数据（如商品信息、用户信息），减少数据库压力，提升性能
• 设计异步处理：订单处理异步化（如订单创建后异步发送通知），提高响应速度，提升性能
• 兼顾可维护性：使用Spring Boot框架（成熟稳定、易于维护），而不是底层技术
• 兼顾安全性：使用HTTPS、数据加密（不影响性能的前提下保证安全）

第二步：确定关键功能——通过4条启发规则识别核心功能

核心思路：通过4条启发规则（核心功能、必做功能、高风险功能、独特功能），从50+个功能点中识别出20-30%的关键功能，从而发现系统需要哪些模块，以及模块如何协作。这解决了业务痛点"需求太多，不知道分析哪些"。

规则1：核心功能——业务层接口中体现的功能

识别方法：看业务层接口，哪些功能涉及多个模块协作？

识别结果：

• “用户下单”：涉及用户模块、商品模块、订单模块、库存模块、支付模块的协作（5个模块）
• “商品搜索”：涉及商品模块、搜索模块的协作（2个模块）

为什么是关键功能：

• “用户下单”：涉及5个模块协作，是典型的（todo：理解ing）模块协作链，通过分析它，可以发现系统需要哪些模块（订单模块、库存模块、支付模块等），以及模块如何协作（订单模块调用库存模块、支付模块）。
• “商品搜索”：虽然只涉及2个模块，但性能要求高（搜索慢会导致用户流失），也是关键功能。

架构决策：

• 设计订单服务模块：处理订单创建、状态管理、订单查询
• 设计库存服务模块：处理库存扣减、库存查询、库存预警
• 设计支付服务模块：处理支付、退款、支付状态查询
• 设计搜索服务模块：处理商品搜索（使用Elasticsearch，不是数据库LIKE查询）

为什么这样设计：

• 解决业务痛点"不知道系统需要哪些模块"：通过分析"用户下单"这个核心功能，可以发现系统需要订单模块、库存模块、支付模块等，从而设计这些模块。
• 业务价值："用户下单"是电商系统的核心业务流程，涉及多个模块协作。如果这些模块设计不合理，会导致订单处理失败、库存不一致、支付失败等问题，直接影响业务。

规则2：必做功能——监管要求或核心业务特性

识别方法：看需求文档，哪些功能是"必须做的"，不做系统无法上线？

识别结果：

• “支付功能”：电商系统必须支持支付，这是核心业务特性，不做系统无法使用
• “订单退款”：监管要求，必须支持退款，不做无法通过监管审查

为什么是必做功能：

• “支付功能”：不做，用户无法下单，系统无法使用。这是电商系统的核心业务特性，必须支持。
• “订单退款”：不做，无法通过监管审查，系统无法上线。这是监管要求，必须支持。

架构决策：

• 设计支付集成层：支持支付宝、微信支付等第三方支付，不自己开发支付系统（节省时间、降低成本）
• 设计退款处理模块：处理退款申请、退款审核、退款执行、退款状态查询

为什么这样设计：

• 解决业务痛点"遗漏关键功能"：通过识别必做功能，可以确保系统必须支持的功能不被遗漏，从而在架构中预留或优先实现。
• 业务价值：如果遗漏了"支付功能"或"订单退款"，系统无法上线或无法使用，导致项目失败。因此，必须在架构中设计支付集成层和退款处理模块。

规则3：高风险功能——性能要求高、技术难度大

识别方法：看需求文档，哪些功能性能要求高、技术难度大、失败影响大？

识别结果：

• “商品搜索”：性能要求极高（响应时间<1秒，支持高并发），技术难度大（需要全文搜索引擎），失败影响大（搜索慢会导致用户流失）

为什么是高风险功能：

• 性能要求高：搜索响应时间<1秒，高并发时要求更高。如果搜索慢，用户会流失。
• 技术难度大：数据库LIKE查询无法满足性能要求，需要全文搜索引擎（如Elasticsearch）。如果技术选型不合理，无法满足性能要求。
• 失败影响大：搜索慢会导致用户流失，直接影响业务。如果搜索功能失败，业务会失败。

架构决策：

• 引入Elasticsearch：作为全文搜索引擎，不是数据库LIKE查询（Elasticsearch支持全文搜索、高并发、快速响应）
• 设计读写分离架构：商品信息写入MySQL（用于管理），同时写入Elasticsearch（用于搜索），保证搜索性能，同时不影响商品管理功能
• 设计缓存机制：缓存热门搜索词（如"手机"、“电脑”）的搜索结果，进一步提升搜索性能

为什么这样设计：

• 解决业务痛点"性能瓶颈或技术风险"：通过识别高风险功能，可以进行针对性的架构设计（如引入Elasticsearch），避免性能瓶颈或技术风险。
• 业务价值：如果"商品搜索"的架构设计不合理，会导致搜索慢、用户流失，直接影响业务。因此，必须引入Elasticsearch，设计读写分离架构和缓存机制，确保搜索性能。

规则4：独特功能——特殊的技术需求

识别方法：看需求文档，哪些功能涉及特殊的技术需求，其他功能没有涉及？

识别结果：

• “商品推荐”：需要机器学习算法（协同过滤、内容推荐），其他功能不需要

为什么是独特功能：

• 其他功能（如商品管理、订单管理）主要是CRUD操作，不需要机器学习
• "商品推荐"需要机器学习算法，涉及特殊的技术需求

架构决策：

• 设计推荐服务模块：处理商品推荐，使用机器学习算法（协同过滤、内容推荐）
• 预留机器学习接口：支持后续接入推荐算法（如协同过滤、内容推荐），避免后续扩展困难

为什么这样设计：

• 解决业务痛点"后续扩展困难"：通过识别独特功能，可以在架构中预留特殊技术需求（如预留机器学习接口），避免后续扩展困难。
• 业务价值：如果"商品推荐"的架构设计不合理，会导致后续无法接入推荐算法，影响业务扩展。因此，必须设计独立的推荐服务模块，预留机器学习接口。

第三步：确定关键约束——转化为功能或质量需求

核心思路：将约束（预算、时间、团队）转化为功能需求或质量需求，从而指导技术选型和架构设计。这解决了业务痛点"约束无法直接指导架构设计"。

列出所有约束：

• 预算约束：预算50万
• 时间约束：3个月上线
• 团队约束：团队5人

将约束转化为需求：

• 预算约束 → 质量需求：选择开源技术栈（Spring Boot、MySQL、Redis），不购买商业软件（节省成本）
• 时间约束 → 功能需求：购买第三方服务（如支付、短信），不自己开发（节省时间）
• 团队约束 → 质量需求：选择团队熟悉的技术栈（Java），不选择新技术（降低学习成本）

为什么这样转化：

• 解决业务痛点"约束无法直接指导架构设计"：通过将约束转化为需求，可以指导技术选型——选择开源技术栈（预算约束）、购买第三方服务（时间约束）、选择团队熟悉的技术栈（团队约束）。
• 业务价值：如果约束无法转化为需求，就无法指导架构设计，导致技术选型不合理（如选择商业软件导致成本超支、选择新技术导致学习成本高、自己开发导致时间超期）。

架构决策：

• 技术选型：Java + Spring Boot + MySQL + Redis（开源，团队熟悉，成熟稳定）
• 购买第三方服务：支付宝支付、微信支付、短信服务（不自己开发，节省时间，降低开发成本）
• 避免新技术：不使用Go、Rust等新技术（团队不熟悉，学习成本高，可能影响开发进度）

第四步：综合决策——架构选型

核心思路：汇总关键质量、关键功能、关键约束，综合决策架构选型，确保架构能够满足所有关键需求。

汇总关键需求：

• 关键质量：性能（主要目标）、可维护性、安全性（次要目标）
• 关键功能：用户下单（核心功能）、支付（必做功能）、商品搜索（高风险功能）、商品推荐（独特功能）
• 关键约束：预算50万、3个月上线、团队5人

确定架构选型：

• 架构风格：微服务架构（支持高并发、可扩展、独立部署）
• 技术栈：Java + Spring Boot + MySQL + Redis + Elasticsearch
• 第三方服务：支付宝支付、微信支付、短信服务

为什么这样选型：

• 微服务架构：支持高并发（性能要求），支持独立部署（可维护性要求），支持水平扩展（可扩展性要求）
• Java + Spring Boot：团队熟悉（团队约束），成熟稳定（可维护性要求），开源免费（预算约束）
• Redis + Elasticsearch：支持高性能搜索（高风险功能要求），支持缓存（性能要求）
• 第三方服务：节省开发时间（时间约束），降低开发成本（预算约束），保证服务质量（质量要求）

长期适配策略：

策略1：基于关键需求持续优化

• 当前状态：通过关键需求方法，已经确定了关键质量（性能）、关键功能（用户下单、支付、商品搜索、商品推荐）、关键约束（预算、时间、团队），并基于这些关键需求设计了架构。
• 长期价值：随着系统演进，关键需求可能会变化（如性能要求提高、新功能增加），需要持续评估关键需求，调整架构设计。
• 实施建议：定期评审关键需求，评估架构是否仍然满足关键需求，如果关键需求变化，及时调整架构。

策略2：在满足关键需求的前提下兼顾其他需求

• 当前状态：架构设计围绕关键需求（性能、核心功能），次要需求（可维护性、安全性）在满足关键需求的前提下兼顾。
• 长期价值：随着系统演进，次要需求可能会变成关键需求（如可维护性要求提高），需要在满足关键需求的前提下，逐步提升次要需求的满足程度。
• 实施建议：在满足关键需求的前提下，逐步提升次要需求的满足程度（如完善代码规范、加强安全措施），但不能影响关键需求。

 

总结收尾

通用应用逻辑公式

关键需求确定的通用逻辑可以总结为：“识别关键质量→识别关键功能→转化关键约束→综合决策架构选型”。

公式拆解：

1. 识别关键质量：列出所有质量需求，识别相互制约的关系，确定主要目标和次要目标。这就像买车，先确定主要目标（省油还是动力强），再确定次要目标（舒适性、安全性）。
2. 识别关键功能：通过4条启发规则（核心功能、必做功能、高风险功能、独特功能），从海量功能需求中识别出20-30%的关键功能。这就像盖房子，先确定核心房间（客厅、卧室、厨房），其他房间可以后期补充。
3. 转化关键约束：将约束（预算、时间、团队）转化为功能需求或质量需求，从而指导技术选型和架构设计。这就像做菜，将"预算有限"转化为"选择便宜的食材"。
4. 综合决策架构选型：汇总关键质量、关键功能、关键约束，综合决策架构选型，确保架构能够满足所有关键需求。

通俗比喻：就像"做菜的完整流程"——先确定"要做什么菜"（关键功能），再确定"要什么口味"（关键质量），最后考虑"有什么食材"（关键约束），然后决定"怎么做"（架构选型）。

可落地的交付物

关键需求确定检查清单：

1. 关键质量识别：

   • 列出了所有质量需求（性能、可用性、安全性、可维护性、成本等）
   • 识别了相互制约的关系（性能vs可维护性、安全性vs性能、可用性vs成本等）
   • 确定了主要目标和次要目标（主要目标对业务影响最大，次要目标必须兼顾但不能影响主要目标）

2. 关键功能识别：

   • 识别了核心功能（涉及多个模块协作的功能，通过分析可以发现系统需要哪些模块）
   • 识别了必做功能（监管要求或核心业务特性，不做系统无法上线）
   • 识别了高风险功能（性能要求高、技术难度大、失败影响大的功能）
   • 识别了独特功能（涉及特殊技术需求的功能，其他功能没有涉及）

3. 关键约束转化：

   • 列出了所有约束（预算、时间、团队、遗留系统等）
   • 将约束转化为功能需求或质量需求（预算约束→选择开源技术栈，时间约束→购买第三方服务，团队约束→选择团队熟悉的技术栈）

4. 架构选型决策：

   • 汇总了关键质量、关键功能、关键约束
   • 综合决策了架构选型（架构风格、技术栈、第三方服务）
   • 验证了架构选型是否满足所有关键需求

最简操作模板：

关键需求确定四步走：
1. 识别关键质量：列出质量需求→识别相互制约关系→确定主要目标和次要目标
2. 识别关键功能：通过4条启发规则（核心/必做/高风险/独特）识别20-30%的关键功能
3. 转化关键约束：将约束（预算/时间/团队）转化为功能需求或质量需求
4. 综合决策架构选型：汇总关键需求→确定架构选型→验证是否满足关键需求

关键需求清单模板：

项目名称：___________

一、关键质量（主要目标 vs 次要目标）
- 主要目标：___________（对业务影响最大、失败后果最严重）
- 次要目标：___________（必须兼顾，但不能影响主要目标）
- 权衡关系：___________（如性能vs可维护性、安全性vs性能）

二、关键功能（核心/必做/高风险/独特）
- 核心功能：___________（涉及多个模块协作，可以发现系统需要哪些模块）
- 必做功能：___________（监管要求或核心业务特性，不做系统无法上线）
- 高风险功能：___________（性能要求高、技术难度大、失败影响大）
- 独特功能：___________（涉及特殊技术需求，其他功能没有涉及）

三、关键约束（转化为需求）
- 预算约束：___________ → 转化为：___________（如选择开源技术栈）
- 时间约束：___________ → 转化为：___________（如购买第三方服务）
- 团队约束：___________ → 转化为：___________（如选择团队熟悉的技术栈）

四、架构选型
- 架构风格：___________（如微服务架构、单体架构）
- 技术栈：___________（如Java + Spring Boot + MySQL + Redis）
- 第三方服务：___________（如支付宝支付、微信支付）

使用建议：

1. 项目启动时：用这个模板快速梳理关键需求，在1周内完成架构设计
2. 架构评审时：用这个模板验证架构是否满足关键需求，确保架构设计合理
3. 需求变更时：用这个模板评估变更对架构的影响，判断是否需要调整架构

 

记住：关键需求是架构设计的"指南针"。通过关键质量、关键功能、关键约束三个核心维度，从海量需求中快速识别真正决定架构的那20%，避免"走错方向"的致命错误，让架构设计在有限时间内聚焦核心问题。正如温昱所说：“关键需求决定架构，其余需求验证架构。”

 

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