1 背景

技术方案设计和评审是版本迭代的一个重要环节，一般情况下版本迭代交付，技术方案设计在2-3天，颗粒度大的需求或者独立项目，这一个环节的时间会适度拉长，但是整体时间还是比较紧凑。技术同学在短时间产出高质量的技术方案是相对困难的，这样评审人对技术方案设计比较难以理解到位、并给出合理建议。本文给出一种面向需求迭代交付的技术方案设计逻辑以解决这一问题，它的核心思想是采用用例驱动设计，基于“演绎法+自上而下”的逻辑来设计技术方案。

2 概要性的设计逻辑

本文的技术方案设计逻辑，基于用例驱动设计。先从需求识别关键用例，接着为用例构造涉及顶层服务交互时序图，之后再自上而下的展开每一个服务接口实现的设计。

1. 关键用例识别：用例是用户或者外部系统与当前系统交互的一个完整的过程，它站在用户视角思考解决用户问题的完整交互流程。这是驱动软件设计的第一步，有了关键用例识别，就可以为每一个用例展开设计。这样整个技术方案设计就具备完整性和推导逻辑。
2. 用例涉及顶层服务交互时序设计：顶层服务是指最外层的服务，你可以理解为RPC服务或者HTTP服务。用户一个完整的交互流程会涉及多个顶层服务的协作完成，交互时序图定义清楚了满足用例的服务交互顺序、服务接口定义、服务大致的实现逻辑。这一步骤是一个概要设计，它不会深入到服务内部的设计，而是偏向服务间的交互契约定义（服务功能、服务接口、服务交互）。接下来就可以从这个交互时序自上而下推导服务接口实现方案设计。
3. 服务接口实现设计：在第2步的概要设计里面，明确定义了服务的功能、服务的接口定义，这一步骤就从服务要解决的功能性问题和非功能性问题展开设计，特别是非功能性问题的定义和满足往往会影响实现方案的设计，比如可靠性问题、可扩展性问题、可维护性问题。举个例子，针对可扩展性问题，可以拆分为规模可扩展性、业务可扩展性。规模可扩展性依靠服务自身性能和服务横向伸缩能力，因此如何提升服务的性能和服务具备横向伸缩就会对服务接口实现的设计产生很大的影响。这里，我们就可能会在功能性问题设计方案基础上，增加缓存组件，以提升性能。

以上3点就是简单的用例驱动的设计逻辑。接下来介绍一下比较完整的设计逻辑。

注：用例驱动设计，非常重要，不仅仅可以用在设计，也在编码、CR、稳定性保障起到很重要的作用，举个例子，目前我们的CR是逐个用例进行评审，每一个用例先介绍顶层服务交互时序图，再Review代码，评审效率和结果提升很多。

3 完整的设计逻辑

架构设计的出发点是用户问题，从用户问题出发形成解决方案，最终落地变成我们的产品需求。产品需求的合理性，就会由用户问题是否准确定义、用户问题解决路径是否匹配、用户问题解决路径涉及的业务流程和规则是否合理决定。技术同学着重关注应用架构、技术架构、数据架构，这三个架构是可以遵循合理的推导逻辑来设计的。一种比较简单清晰的推导路径分成四个阶段、九个步骤， 如下图所示。

• 需求分析：对需求进行结构化分析，明确需求要解决的问题、实现路径、实现路径涉及的业务流程和业务规则，最终抽取出参与者与系统关键用例。注意：系统关键用例非常重要，它是整个技术方案设计的第一步，即用例驱动设计。
• 应用架构设计：从系统关键用例出发，勾勒出需求的所有用例场景，用例涉及的应用、服务及其之间的依赖关系，然后详细设计用例涉及的服务的交互时序图，并明确服务的接口定义和非功能性要求。应用架构是一个高层的设计，拉通了整个团队对需求涉及的用例及用例实现中涉及服务的具体交互流程的认知，定义了应用、服务间的实现契约。注意：这里用例服务交互时序图只涉及服务及核心流程，不用太细化到服务的具体实现，也就是说每一个服务只有一个Lifeline，在里面的每一个步骤简单描述。
• 技术架构设计：从应用架构中定义的服务接口展开，针对服务接口的实现进行设计，需要分析服务接口实现的功能性、非功能性需求，准确识别服务接口实现需要解决的问题，然后设计相应的解决方案，特别是非功能性需求的满足需要通过合理的技术架构的设计来保障。比如，解决直播库存秒杀问题、解决库存超卖问题、解决出价分布式一致性问题、解决商品详情模块化扩展问题、解决收藏大数据实时查询问题等，用例中对这些问题的定义可以推导出合理的解决方案，将解决方案用图形化方式表示出来，就整体形成技术架构设计。非功能性需求，可以分类为可靠性需求、可维护性需求、可扩展性需求、效率与成本需求等。
  • 可靠性需求可以通过SLA进行目标定义，SLA可以拆分为SLO、SLI，比如服务接口在规定响应时间的响应成功率、分布式事务一致性比率等，然后设计相应方案来保障。
  • 可维护性需求核心在于控制复杂度，尽量使用简单的设计来满足可维护性。可以采用成熟的架构风格、设计模式应用在服务实现中，比如分层、插件化（模块化）、管道过滤器、组合模式等。
  • 可扩展性需求则重点考虑规模的扩展和业务规则的扩展，规模的扩展要求能够进行横向扩缩容，需要至少满足无状态设计，而业务规则的扩展则可以应用扩展类的架构风格与设计模式。
  • 效率与成本需求是对技术架构设计形成约束，即服务的实现是要考虑成本的，尽可能具备高的性价比。
• 数据架构设计：从服务接口实现方案出发，设计合理的存储架构满足服务的功能性和非功能性需求。数据架构需要描述清楚所依赖的关系数据存储、列式数据存储、高速缓存、索引、离线计算、实时计算等，以及具体的数据模型（可用使用ER图表示），此外，还需要兼具考虑事务处理性能、数据分析性能等需求。

架构设计基于用例驱动设计，通过“演绎法 + 自上而下”进行推导设计的。首先，从业务需求到IT架构（应用架构、技术架构、数据架构）是层层推导设计的。其次，应用架构来自全局的用例场景及用例涉及服务交互，它是概要性的设计；技术架构和数据架构则是应用架构服务接口定义的具体实现的方案设计，需要针对服务接口实现的功能与非功能性需求进行设计；从应用架构到技术架构与数据架构是自上而下（或者由总到分）的推导。

详细的各部分设计逻辑可以参考：规范-技术方案设计，本文详细介绍了如何做需求分析、如何做应用架构设计、如何做技术架构设计、如何做数据架构设计等内容。

4 关键的两类图：用例图和时序图

4.1 用例图

三部分组成：参与者、用例、参与者与用例之间的关系。

参与者：不是特指人，是指系统以外的，在使用系统或 与系统交互中所扮演的⻆色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。

用例：是对包括变量在内的一组动作序列的描述，系统 执行这些动作，并产生传递特定参与者的价值的可观察结果。

关系：参与者与用例之间的关系主要包括关联、归纳 (泛化)、包含、拓展和依赖。

用例图中的关系描述如下：

A）关联：表示参与者与用例之间的关系;

B）泛化：表示参与者与参与者之间、用例与用例之间 的关系，一个用例可以被特别列举为一个或多个子用 例，这被称为用例泛化;

C）包含：表示用例与用例之间的关系，其中一个用例 (基础用例)的行为包含了另一个用例(包含用例)的 行为。用来把一个较复杂用例所表示的功能分解成较小的步骤;

D）扩展：表示用例与用例之间的关系，用于拓展用例对基础用例的增强;拓展用例是在特定条件出现时，才会被执行的用例。

4.2 时序图

时序图是基于交互的对象行为建模，是 UML 用于描述 对象之间信息的交互过程的方法，是描述对象间协作关系的模型。

时序图用于捕获系统运行中对象之间有时间顺序的交互，是由生命线和消息组成。

时序图将交互关系表示为一个二维图。纵向是时间轴， 时间沿竖线向下延伸。横向轴代表了在协作中各独立对 象的类元⻆色。类元⻆色用生命线表示。当对象存在 时，⻆色用一条虚线表示，当对象的过程处于激活状态 时，生命线是一个双道线。消息用从一个对象的生命线 到另一个对象生命线的箭头表示。箭头以时间顺序在图 中从上到下排列。

时序图要素说明如下：

A）⻆色：用户、外部系统等。

B）对象和生命线：对象的命名可以是类名、对象名、 类 + 对象名，生命线为虚线表示对象存活的时间。

C）活动条：在生命线的虚线上可以用活动条来表示某 种行为的开始和结束，一般用矩形表示。

D）消息：对象的行为称为消息，对象调用另一个对象 的行为即完成一次消息传递。分为：简单消息、同步消 息、异步消息。此外，还有自我调用消息、消息的返回值。

E）交互框：选项 opt、抉择 alt、循环 loop、并行 par 等。

5 参考模板和范例

以下是出价定义的技术方案参考模板，不同的模板对设计逻辑进行裁剪和调整。对于版本迭代，大部分需求设计可以采纳V3版本的方式来设计。这里附上了相应的参考范例，供大家参考。

6. 结论

本文探索了基于用例驱动的架构设计逻辑，核心思想是采用用例驱动设计，基于“演绎法+自上而下”的逻辑来设计技术方案，帮助开发人员理清技术方案设计思路并提升技术方案的质量和评审效率。完整的架构设计背后简单清晰的推导路径分成四个阶段、九个步骤，简单实用，如下所示。

各个阶段的产出成果如下。

• 需求分析阶段产出成果
  • 业务流程图（活动图或流程图，泳道或非泳道）
  • 用例图
• 应用架构设计阶段产出成果
  • 应用、服务规划
  • 用例涉及顶层服务交互时序图
  • 服务接口定义
• å技术架构设计阶段产出成果
  • 服务接口实现的设计方案
• 数据架构阶段产出成果
  • 服务接口实现的存储方案
  • ER图

*文/Lorry

关注得物技术，每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～