中台之建模篇

建模是架构设计中非常重要的环节。本文将介绍中台架构设计过程中业务建模和数据建模的主要原理和方法。

模型
什么是模型？模型就是所研究的系统、过程、事物或概念的一种表达形式。表达既可以是高度仿真的，就像建筑模型一样，也可以是高度抽象的，比如高达玩具模型，以及在软件开发中经常使用的对象模型、时序模型、用例模型，都是抽象的。

建模
建模就是建立模型的过程，模型包括了组件以及构成关系。首先是要识别模型中组件，通常采用分类和抽象的方法。分类就是根据事物本身的属性、逻辑关系或者框架来进行分类，如我们经常把业务分成 To B 的业务和 ToC 的业务，把商品分成虚拟的商品和实物的商品。抽象是为了简化，将业务概念进行抽象重新进行聚类，比如收银员，经理，在数据建模的时候，可以统一把它抽象为职员。在需要关注不同角色的时候，可以再把它泛化成收银员和经理两个具体角色。

有了组件的识别，还要对组件进行关系的重构，在重构的过程中既要考虑仿真，也就是还原事物的特征，还要去考虑要表达的目的或意图是什么，也就是关注点是什么，比如关注的是业务过程，就会采用功能分解模型。功能分解模型将识别出活动、任务。再识别具体的活动、任务里面的再提取出具体业务需求，也就是功能。如果关注的是业务对象，就会采用对象协作的模型。对象模型识别业务对象和对象之间的协作关系。

关注点不同，就会采用不同的模型。举个关注点的例子。大象塞进冰箱，需要几步？答案可能大家都知道，需要两步：第一步，打开冰箱。第二步，把大象塞到冰箱里面。从逻辑性上看并不合理，但实际上可以理解为这是高度抽象的模型。这个模型只关注的大象和冰箱之间的位置关系，忽略了次要因素，如大象的体积。从建模的结果看，识别出来的两个步骤，打开门和放进去都是两个必须的关键步骤，至于下一步具体怎么放，可以再分析。这个模型的意义就是要提前识别出冰箱是闭合结构。在把大象放进去之前，就可以先去考虑门是不是可以打开的这个事情。如果没有识别出关键步骤的话，可能后续的所有工作，就是毫无意义的。所以模型既要考虑它仿真的一面，也要考虑关注点，通过关注点简化模型。在模型里面还有非常重要的概念，就是元模型。元模型就是模型的模型，可以理解为模型的框架或模板。有了元模型那么建模的时候就不用再去考虑组件分类，元模型已经通过模板给你分类好了。比如 MVC 框架，就可以理解为元模型，你只要把这些识别出来的控制对象、实体对象组件往里面填就可以了。元模型会大大简化建模的过程。

当然在使用元模型的时候，要注意上下文。在企业架构里面，通常要对企业内容元模型进行裁剪，这是要特别注意的。建模没有统一的标准和答案，这是知识密集型的过程，完全取决于人的智慧，是架构师要特别去培养的一种能力。

接下来就看在中台架构设计过程中两个主要的架构领域的建模。

业务建模
业务建模关注的是业务流程、活动和任务，它描述了企业管理和业务所涉及的业务概念，以及它们的属性、行为和彼此关系。业务建模方法如 BPMN、UML、业务场景以及四色建模法等。业务建模首先要识别业务概念，业务概念是对企业重要的人、事、物，例如在银行业务里面，“人”包括个人用户、企业用户以及银行柜员。“事”包括各种银行业务如存款、贷款、承兑。“物”包括 ATM 机、门店、网上交易系统等。

业务概念是怎么来的呢？业务概念是通过业务模型识别出来的。以业务场景建模为例，一个典型的业务场景可以通过“谁”“何时/何地”“做什么”来描述。

以银行业务为例，有三个典型业务场景描述：

个人用户通过 ATM 机进行自助存款；

企业用户通过门店在低柜办理贷款；

银行营业员/柜员，通过网上交易系统为企业用户能办理承兑业务。

有了业务场景描述，我们分析它的语言结构，把主语、谓语、定语剥离出来。主语通常识别的是“谁”，对应业务模型里面的“干系人”。谓语识别的是“做什么，”比如说存款/贷款/承兑，对应的就是业务模型里面的活动和任务。定语识别的是“何时何地”去做这件事情，对应的是业务模型里面的组件“事件和地点”。这样就可以通过业务场景描述中的语言结构分离出业务模型里面的这些业务概念。业务概念进一步可以抽象为业务对象。

银行业务模型的示例
业务对象之间必然存在的逻辑关系，把这些逻辑关系梳理出来，让他们相互关联，就构成了业务对象模型。

金融行业业务对象模型

图中展示了金融行业的业务对象模型，它包括了当事方、协议、产品、角色、账户、交易等。

当事方、协议、角色存在组合关系。角色和协议组成了当事方，或者说当事方由角色和协议这两个组成。协议是当事方和银行之间的合同条款。举个贷款的例子，在贷款业务里面，当事方可能包括两个角色，是担保人，是借贷方，当然还有是贷款方，贷款方就是银行，所以不用去识别贷款方，只识担保人和借贷方两个角色，当事方就包含了那担保人和借贷方。协议包括了担保协议和贷款协议。产品和服务就是指的贷款业务。服务还对应合约。合约实际上是产品的实例化。实例化的合约，通常关联到合同条款。基于这些业务关系，把业务对象关联起来，就构成了业务模型。

数据建模
数据模型是信息的输入和输出，它通常以实体关系图（ER）为基础进行构建的。实体关系图按照业务对象进行划分，将数据的属性按照实体进行聚类，并描述实体间的关系，从而指导后续的程序设计以及数据库的设计。

元模型
在企业进行数型建模的时候，可以采用一种分析框架，也就是架构元模型。架构元模型定义概念并提供用于创建该领域中的模型的构建元素，元素包括组件及其关系。例如银行的 FSDM 模型，就是金融行业的架构元模型。元模型已经把分类和关系给你构建好了，你建模的时候只要按照分类标准，去往里面塞具体内容就可以了。

银行 FSDM 模型

在 FSDM 模型里面，数据实体分成了九个大类，干系人、合约、条件、产品、地点、分类、业务对象、事件和资源项。干系人就是银行业务开展相关方，比如个人、企业、银行柜员。合约就是参与者之间达成的合同协议。条件是银行开展业务的所需要的前置前提、资格标准和要求。产品就是银行为客户提供的服务。地点就是客户的地址，公司的地址。

FSDM 九大概念之间的关系(架构元模型)

有了数据实体的分类的标准，可以再去建立它们之间的关系。在 FSDM 模型里面，关系也已经构建好了。比如在这张图里面可以看到参与人，产品，合约之间存在的关系，银行和客户它是建立了一种合约关系；客户拥有产品；产品由实例化为合约。这三者的关系，实际上是通过 FSDM 模型你就构建好了，你在建模的时候，你只要识别出来谁是参与人，谁是产品，谁是合约，按照模型往里面套就可以了。这张图里面把所有的业务实体的关系都梳理出来。

实体
实体是数据模型里面要识别的组件。实体的定义，通常都是一些“名词”。比如员工，公司，商店，这些都是实体。实体有或多个属性。实体可以按照不同的分类标准进行分类。IBM 有 Industry module 分类标准，是按照含义分类的，例如“安排（how)” ,“业务指导（how)”,“相关方（who)”,“产品（What)”，“资源（What)”，“位置（where)”。除了按照含义来进行分，也可以按照它的模式进行分类，比如按照主实体，子实体，属性实体，关联实体。还可以模型类型进行分类，包括比概念实体、逻辑实体、物理实体。

有了分类，关系自然就出来了，所以建模有时候就是分类。分类和关系有了，把这些分类后的组件按照关系连接起来就构成了数据模型。

业务对象通过数据实体进行落地
业务模型和数据模型的联系和区别在于：

数据模型的输入是业务对象，而业务对象是业务模型的输出；“输入－处理－输出”合起来就是流的处理过程。

数据模型和业务模型关注点不同，数据模型关注的是输入输出，是信息的构建过程；业务模型关注的是业务处理，包括事件、活动、任务。

数据模型里面，经常会采用概念模型、逻辑模型和物理模型三层建模的一个模型框架。概念模型从业务角度分析业务对象之间的联系。逻辑模型它从逻辑数据实体之间的关系去描述业务规则。到了物理数据模型，就是按照一定的规则和方法，将逻辑数据模型里面，定义出来的这些实体、属性、约束、关系等内容转化为数据库里面的具体的物理实体关系（表-段-区-块）。以电商里面的销售订单为例。在概念设计阶段我们可以通过业务建模的一些方法识别业务概念/业务对象，例如识别出订单。

逻辑数据建模会把业务对象也就是订单，进一步分解为订单头和订单行。订单头包含销售订单的公共的信息，例如总价、订单编码。订单行是实体属性的归类信息，例如商品信息和供应商信息，商品信息包括购买了哪些商品？它的单价，它的数量。供应商的信息包括供应商的名称、供应商的编码。订单头和订单行是一对多的关系。订单头和订单行都是逻辑实体。在 DDD 里订单头又被称为聚合根。订单行是实体属性归类拆分出来的逻辑实体，它不是单独立存在的，必须是通过订单编码关联到订单头里面。通过分解过程可以看出：

逻辑实体是业务对象属性聚类的结果；

业务对象和逻辑实体不是一一映射的关系；

逻辑实体可能是抽象的概念，比如订单头。

业务对象在业务建模和数据建模里面是承上启下的一个关键节点。业务对象最终是通过数据模型来进行落地。反过来讲，数据建模的时候也要重新回溯到业务，去识别业务概念里面的这些关键的概念，再从业务概念抽象为业务对象，然后再把业务对象的属性归类为新的逻辑实体，最后将逻辑实体通过一定的规则分解为物理表。所以业务建模和数据建模，实际上是殊途同归，最终都会落到业务对象到实体的抽象，以及实体关系上面。

中台一体化架构

中台架构包含了业务架构设计阶段，构件设计阶段，系统设计阶段。

业务架构设计重点是要识别需求，通过业务建模识别活动/任务/业务对象，最终输出业务对象模型。

构件设计包含了应用建模以及数据建模。应用建模将业务架构建模阶段识别出来活动/任务进一步细化，并将这些细化的活动/任务重新按照应用组件的方式进行聚合。同时，在构件设计阶段，还包括数据建模，它将业务对象进一步抽象为数据实体，并构建数据实体之间的关系。

系统设计阶段通常采用 UML 用例模型进行建模，并通过建模识别出系统组件。这些系统组件可以按照业务逻辑进行聚合，也可以是从实现的角度进行聚合，并通过微服务进行开发，以 API 接口的方式，提供给前端的业务。

在整个设计活动中有两个关键的节点，一个是能力，另外一个就是业务对象。

能力是在企业架构里面非常重要的一个概念。能力它关联了战略，关联了需求，关联了业务组件（活动/任务）

业务对象连接了业务模型、应用模型和数据模型。从业务对象到数据实体到数据表，它是连贯的分解的过程。

建模过程中，如果能抓住这两个关键节点，整个中台设计过程“战略-业务-应用-数据”才能成为一个有机的整体。

业务就是数据，数据就是业务。企业未来的作战它必须是基于业务数据一体化的视角，而不是分裂的视角。