这个话题源自于SDK部门设计标准的推导。我看过很多介绍技术模型的文章，大部分都是介绍从实体的角度如何画技术架构图。但真正介绍业务能力相关的业务模型却很少。这是因为业务的抽象复用要比技术的抽象复用难得多，而我要介绍的是以SDK设计的角度去分析如何构建一张属于SDK的各个业务的模型图。

对接业务是每个开发需要做的事情，对于每个业务的负责人有义务讲好自己业务模型的“故事”，引用《人人都是架构师》的一句话：

架构的事情谁来做呢？看一下你座位左边的，再看一下你座位右边的，再看一下你主管.... 别看了，他们是要做，你自己也要做，人人都是架构师。

什么是业务模型图？这个问题在我刚开始实践画业务模型图的时候很困扰我，在我们日常工作中经常能看到各种各样的有关架构或者是模型的图，大家对这些图的理解千人千面，有的会把业务模型图当成是一个流程图，有人会把它等同于业务架构图，也有人会将它理解成是一个介绍业务的图例。没有人给出一个具象而标准的定义，我尝试将这个问题进行如下拆分。

业务模型图 = 业务模型 + 图

问题拆分后，则需要解决两个问题：

●业务模型是什么？

●图是什么？

图是什么？这个问题不难回答：业务模型图是业务模型的具体表达！有点绕？没关系，可以用一个等式表达：图 = 业务模型图 = 业务模型的表达 = 表达业务的模型。

所以我们要解决的问题转为了：业务模型 + 表达。



通过抽象、聚合、分类等方式，对业务的能力内容、职责范围（边界）进行定义。

尝试回忆一下，你是否遇到过这种情况：当别人问你负责的业务具体是做什么的（业务本质）？为什么要这么设计？未来计划怎么玩（业务扩展）？你很难用一两句话跟别人讲清楚这些内容，就算你花了很多时间跟别人解释这些事情，他们还是很难听懂你在讲什么，特别是跨了业务协作、跨域协作（产品、研发、UED），在SDK领域必须面对的还有对上游的解释，跟他们说清楚对接的模式、对接的方式等等。这时候恨不得把代码掏出来一行行的讲给他们听，但就算你把代码掏出来，也很难讲通整个过程，这是因为每个人的认知背景存在较大差异。

而业务模型及其推导过程可以帮你总结和思考这些东西。

其受众用户和应用场景：

○研发：了解模块的能力拆解思路和演进逻辑，形成研发内部共识，重点应用在需求承接过程中对必要性和合理性的判断，或者对模型提出调整建议，形成新的共识。

○产品：了解HMI、研发、UED等之间的分工逻辑，重点应用在对于需求合理性的判断以及客户/竞对价值的挖掘。

了解清楚业务模型的内容和作用后，接下来要解决的是“图”如何表达出来的问题。

业务模型要说清楚需求背后的能力演进逻辑，主要包含三个部分的能力内容：

●业务内核：高层次抽象业务关键的模块拆解逻辑，需要对现在需求的全面覆盖对未来有很好的扩展考虑。

●基础能力：在业务承接的基础上抽象高可复用能力，重点保障业务演进过程的高性能、高质量、开发效率，从分工的角度能够让业务开发的团队给框架的同学讲清楚职责要求。

● 对接模式：从SDK平台型产品特点出发，需要明确SDK使用者的对接模式，追求的是更低的对接成本和更专业的个性化能力。



一图胜千言，业务模型核心还是要通过整体的架构图来表达。架构核心是横和纵的考虑。在横的方面，首先需要选择SDK业务架构的分层模型，能够让各模块业务在推导过程中能够有相似的表达习惯。

业务架构分层模型可以从业务模型本身想表达的内涵出发考虑：

○面向HMI（Human Machine Interface 人机交互界面）：SDK作为能力提供者，需要满足HMI（用户）对业务能力的诉求，在提供业务能力的同时降低HMI的对接门槛。

○面向底层：基于引擎/数据/基础库提供的原子能力，进行初步封装。主要重点保障业务的质量、业务开发效率、业务稳定性的沉淀。

故而业务分层模型可以参照以下的分层结构进行分层，但不局限于这种分层接口，需要根据自身业务情况来定。

• HMI层：基于SDK的业务组件层或模式层的能力，明确业务场景分类逻辑和SDK对接模式；

• 业务组件层：在模式层的基础上，面向HMI使用场景的业务封装，需要有清晰的个性化分类特征，如何满足不同层次的诉求；

• 模式层/框架层：描述业务本质流程的核心业务能力构成；

• 通用能力层：业务流程无关但是业务依赖的通用能力；

• 基础库/引擎层：涉及到SDK用到的引擎或者基础库的核心能力；

业务模型的推导过程也是建模的过程，行业中有很多建模的经验可以参考。其中不局限于建模的具体方法，而是在于建模背后方法论。有几个方法选择更加适合SDK业务特点。整体的推导过程采取“自底向上和自顶向下的结合”的方法论进行推导：

●自顶向下

●自底向上

●自底向上和自顶向下结合

○基于自底向上的建模结果和自顶向下的全局拆解逻辑互相印证、反复调整，保障模型整体自洽。

整体流程大致如下：



业务模型是的推导过程是一个分类的过程，分类的过程背后是逻辑推理的过程。逻辑推理的两种基本模式：归纳和演绎。通过大量的产品PRD作为信息输入，使用合理的拆解方法，将需求的输入信息拆解成不可再分小点，再尝试使用业务能力的分类标准将其分类，探求不同分类的可能性，最后将能力根据关系组成有层次、关系明确的业务流程、能力关系图。



本文章主要介绍自底向上的推导方法论，自顶向下的方法论这边不做论述。整个推导过程分为了6个步骤：需求收集、能力拆解、能力定义、能力分类、能力分层、数据关系。

那为什么是这六个步骤呢？这个问题是个很好的问题，根据我们的推导原则和大量的实验论证，业务模型是基于现有的所有业务（需求），将需求拆解成分散的程序能力项，根据分散的能力项重新组合行成完整的业务结构。故而整体的流程是需求拆能力，再归纳和演绎成业务模型。总体推导过程需要分6个步骤去实现。



具体步骤和执行标准详情见下文。

能力拆解

能力拆解是将产品的Prd转化为一个个具有业务能力的能力项的过程，整个拆解过程较为繁琐。我们经过探索，总结出一个执行方式：

●需求拆解成事件集合

●将事件即可拆解成不可再分的能力子项。

这些能力子项，我们称之为：“能力项列表”。这些能力项是完成产品Prd，组成整个业务模块的砖头。

名词解释

事件：是指对领域状态产生重要影响的事件。它通常代表了一项业务事宜的完成或一个重要的变化，例如“用户注册成功”、“订单已支付”、“库存已更新”等。业务事件通常以过去时态的形式描述，因为它们代表了系统所经历的某个瞬间的状态变化。

在能力拆解者的视角中，需求的样子：



具体的操作步骤不再这边详细展开，有兴趣可以看DDD设计相关内容的介绍。

名词解释（引用维基百科）

DDD：领域驱动设计（英语：domain-driven design，缩写 DDD）是软件代码的结构及语言（类别名称、类方法、类变量）需符合业务领域中的习惯用法。是一种架构设计方法论，通过边界划分，将复杂业务领域简单化，帮助我们设计出清晰的领域和应用边界，保证业务模型与代码模型的一致性。

这个步骤将需求拆解成事件集合的过程，要关注事件拆解是否出现遗漏，是否准确！！需要穷举客户事件，明确客户所有场景和业务操作，对于不同的消息事件列表，如果处理逻辑不一样，需要穷举所有消息类型。这个很重要，如果事件拆解的过程出现遗漏，则最后可能出现业务模型的能力项丢失。

这个步骤拆解的结果是得到了事件集合，作为事件拆解成能力项的输入。



在事件拆解的原则中，一个事件可以认为是需求的一个case，对其拆解可以得出完成需求所需的能力项列表。而在拆解过程中一个事件需要对其进行完整的描述，保证拆解的能力项是完整的、不可再分的。

我们要关注的点主要有5大要素：资源、数据、业务、配置、异常。这五大要素描述了事件的输入、输出、依赖、场景变化、异常情况等信息。通过这五大要素，解释了完成一个事件的所有能力项的完整叙述。具体内容：

●资源：事件资源是运行必不可少的数据内容。比如车标显示，则需要车标的样式资源数据。

●数据：事件数据是对事件中所关联的数据以及数组组成的静态描述，需要明确数据项的组成成员，数据流中不再描述数据项具体组成。

●业务：

○业务需要包括触发场景、数据流、事件处理规则、以及场景对应场景操作；

○规则需要明确数据流的所有处理规则，规则不包括用户事件，用户事件需要事件风暴的事件体现；

○场景操作需要指出APP视觉领域的变化，包括UI、主图、图层；

●配置：需要明确客户在这个过程中使用的配置项，如缩放系数等。

●异常：需要明确业务处理过程中，SDK可能发生的异常。



事件经过五要素拆解后，得到的输出：“毛坯”能力项，这时的能力项包含了主语、宾语、谓语、定语、状语等等。

本环节的输出作为“能力定义”环节的输入。

能力定义

能力定义是对能力拆解后得到的“毛坯”能力项进行进一步的精细化加工，和针对具象能力的定义。原则是在能力精简的基础上，不丢失原有的能力信息。

能力精简

业务能力项精简是去除多余修饰部分（状语、补语等），进行简化。在此基础上可以对能力进行简单的归纳。此步骤能够化繁为简，减少后续能力分类的工作量。拿拆解后的其中一个能力项举例分析，该能力项的背景是：在高德地图车机版上，用户点击“回家”按钮后，规划了一条路线，用户选择路线后，点击“开始导航”后，开始进入导航状态并播报前方路况。



此时，可以去掉对能力项不影响的部分，保留能表达能力项的部分，则会得到两种情况：

第一种：只去掉无能力项无关的修饰，通过这种方式得到的能力项信息较多。



第二种：在去除与能力无关的修饰基础上，进一步去除过度描述业务的名字。



对比这两种方式，我更倾向于使用第二种方式，是因为在充分描述能力的基础上，可以做到更精简的描述业务的能力。在后续的能力分类上可以更好的判断分类原则。

能力去冗余

●原则：去除相同，保留不同。

●做法：在业务能力精简后，再去除相同的能力，只保留一个。

举栗：在实际事件拆解过程中，拆出了两个事件：开始导航事件和结束导航事件。这两个事件分别有通知用户开始导航状态、通知用户结束导航状态，则这两个能力项可以认为是同一个：通知用户导航状态。

●评价标准：在实操过程中主要是关注以下原则：

在实际操作测试中，通过不同需求的两个事件的操作，对其进行能力拆解和能力定义，经过能力拆解、能力定义后，两个推导步骤下来相似的事件中能力精简了55%。我们在推导过程中可以抽象出事件很多共性的部分。

能力分类

经过能力定义后，会得到不可再分的精简能力项列表，至此已经没有需求的概念了，你手上有的只有一堆混沌、杂乱的能力项列表。我们需要在混沌的世界里面重新建立一个新的秩序、新的世界。这时候对付这种混沌的世界，我们使用聚类工具让他们“闻风丧胆”，重新回归有序。执行原则和方法，是使用最小生成树聚类。在分类执行过程中，业务专属的特定分类原则应优先于通用的分类原则，这是快速的拉齐概念一致的方法。其执行标准如下表：

虽然有共同的执行标准，但对于能力分类的结果而言因人而异，不同人归类的结果必然或多或少存在不同，故而需要在归类之后反复的check是否归类合理，合理性的评价标准如下：

1.完整性：check是否考虑全面；

2.结果独立互斥：check能力分类是否只符合单项；

3.清晰易懂：概念清晰、不需要进一步解释；

4.叶子节点的颗粒度相当。

当分类的结果符合以上的评价标准，则对于相同的事件分类结果将殊途同归，最后结果差别不大。

操作示例

下图使用简单的形状表示不同的能力项，初步分类将业务相同的归为同一类，从20个能力项得到了8个类别。再通过功能分类相同的归为同一类，进一步抽象得到了3类业务功能能力。最终从20个能力项变成了3类业务能力，这就是抽象之美。



能力分层

能力分类后将得到能力类列表，此时的类列表在结构上还有所欠缺，无法表达能力类之间的层次关系和结构关系。故而类间关系明确，类之间的关系为类的进一步聚合能力类和类的分层提供了理论支撑。此时我们借鉴程序设计中类关系的定义（但不完全相同）对能力类之间进行关联，进一步确认类关系。

步骤1：关系明确

根据依赖关系进行初步分层，进一步组合和结构划分，得出基础的分层结构图。

层（块）关系执行准则：

●并列关系：业务属于同一大类型，但业务之间没有交集。则作为一个原子能力被依赖或组合。

●组合关系：根据业务的分类标准对业务能力进一步分类组合，再抽象出一个程度更高的能力分类，被能力类作为子类的形式呈现。

●依赖关系：被依赖的业务能力作为依赖方的基础能力，被依赖的业务能力作为基础能力。

步骤2：引入分层模型

在分层结构图的基础上，确认业务的核心能力、业务组件能力、基础能力，根据经典分层结构填入指定层。具体的分层结构需要根据自己业务情况进行制定，这边提供的经典分层结构是SDK开发中常用的分层结构。

●业务组件层：业务对接能力抽象，解决SDK对接能力的易用性和个性化问题。

●业务模式层：业务核心能力，描述整体业务模式。

●基础能力层：向下对接引擎能力，向上为业务核心提供能力支撑。



评价标准

在分层操作中，更多的需要关注分层是否合理，以及好不好理解，所以主要关注以下两点：

●合理性：check是否存在分类的分层不合理；

●清晰易懂：概念清晰、不需要进一步解释。

操作示例

对能力分类后的能力类列表进行类关系明确（左图），再根据类关系将其填入到分层模型中，将会得到一张接近完整的业务模型图。



数据关系

业务模型的大厦在能力分层后即将成形，只剩最后一片乌云：业务能力层之间的数据的流转情况。该步骤主要解决层/块之间的关联操作的数据关系。在数据关系中，主要关注什么数据（WHAT）和怎么流转（HOW），也就是业务运转需要什么数据和对应数据的流向是怎么样。首先是数据定义，其归纳的执行标准如下：

●业务特性：根据实际业务模块定义；

●通用特性：能力与能力、层与层之间的交互出入口的数据和对应控制类型的集合。

其次是数据流，其归纳的执行标准如下：

●单向数据流：数据只朝一个方向流动（没有反馈控制的处理结果）；

●双向数据流：数据可以在两个方向之间流动（反馈控制的处理结果）；

●参与者与角色：数据的生产者（生成数据的系统）与消费者（处理或使用数据的系统）。



评价标准

在数据关系中，最后check的部分主要关注在数据的完整性和清晰度上，主要为：

●完整性：check是否考虑全面；

●清晰易懂：概念清晰、不需要进一步解释。

操作示例

根据层与层之间的数据集合进行分类，假设得到了“xx业务控制”、“xxx业务控制结果通知”等数据类，对其数据流向进行定义后填入到图中，将得到右图完整的业务模型图。



在业务模型图出来后，需要反复check业务模型是否符合业务情况，主要需要关注以下几点：