模型驱动方法论在业务中台中的实践研究(一)

李忠民 何鑫

摘  要：在某大型央企的业务中台的建设过程中对模型驱动架构方法论进行了系统深入的研究，结合工作实践提出了一个可行的模型序列，并总结出了一套模型转换规则，之后进一步采用该方法论指导了中台项目从分析、设计到落地的整个生命周期，实现了模型驱动架构在业务中台项目的应用。文章对实践经验进行总结，重点就模型驱动架构的主要内容——模型序列及其转换规则展开讨论。

关键词：模型驱动架构;业务过程建模;用例模型;组件模型;模型转换

中图分类号：TP311.52       文献标识码：A 文章编号：2096-4706（2020）17-0129-03

Abstract：In the process of the construction of a large central enterprises financial middle office，this paper makes a systematic and in-depth study on the MDA methodology，puts forward a feasible model sequence and summarizes a set of model conversion rules，and further adopts the methodology to guide the analysis，design and implementation of the project，so as to realize the whole life cycle of the project and realize the fall of MDA in the financial center project. This paper summarizes the practical experience and focuses on the main content of MDA model sequence and its transformation rules.

Keywords：MDA（model driven architecture）;business process modeling;use case model;component model;model transformation

0  引  言

最近，北京中電普华信息技术有限公司承建了某大型央企业务中台的建设任务，业务中台作为某大型央企的企业级应用，支持该企业总部和全国范围的分支机构的相关业务。该企业在此前已经长期进行业务信息化建设，存在着数十个分立的业务系统，就像大多数企业一样，这些系统呈烟囱状，已经对企业的数字化形成阻碍。在此情境下我公司实施了中台战略，业务中台作为该战略的一部分，其目标是采用新的架构，继承已有信息化成果，抽取公司各领域的有复用价值的业务模块集成到业务中台中，为该企业各业务条线提供公共服务。业务中台是该央企的关键应用，业务复杂、涉及范围广、架构先进，相关领域的实践不多，可资借鉴的经验不多，因此设计一套成熟的、系统化的方法论来指导业务中台的建设至关重要。

模型驱动架构方法论对系统分析和设计领域进行了概括和抽象，把系统分析和设计过程抽象为一系列前后依赖的模型的建模过程，其核心思想是只要对该序列的模型依次建模，就可以从业务逐步逼近实现，最后达到实现。该方法论给出了一个完整的、系统化的、前后衔接一致的解决方案，其覆盖了从需求分析、系统设计、到系统实现的全生命周期，实现了业务需求的结构化描述，利用严谨的建模语言描述了结构、数据和行为，为系统的分析设计提供了一条逻辑严谨、步骤明确、接近可推理演算的实现方法;它可以确保设计反映业务，针对业务展开设计，确保设计意图贯彻到实现中去，从而让客户更有可能获得他们真正需要的系统。

但模型驱动架构（MDA）方法论只是提出了一个抽象的

理论，距离落地实施还有一段距离：首先其并没有给出具体的模型序列，其次亦没有给出模型间的转化规则。故模型驱动架构方法的落地仍需实践者自己去探索，去找到模型序列，并给出模型间的转换规则，补齐抽象的方法论与具象的实践间的空白。尽管这样，MDA的思想在某些局部已得以实现，若借助市场上现有的CASE工具，再辅以人工编写的一些脚本，是具备落地实施的可行性的。作为业务中台的承建单位，公司认识到模型驱动架构的优势，结合业务中台的建设任务展开对MDA方法论的深入研究，并利用MDA指导业务中台的建设实施。本文结合作者在业务中台设计开发工作中的实践，提出一个可行的模型序列，并在后续系列文章中给出模型转换规则。

1  模型驱动架构及其适用场景

在《应用MDA》一书中，作者提出“XP的核心部件是3GL代码，而MDA的核心工件是模型”，这句话道出了MDA的本质，说明了MDA和时下流行的各种设计方法的区别，MDA更加重视设计，甚至试图以设计代替开发。MDA适用于传统的、注重设计的重型项目，但这并不意味着MDA在敏捷开发大行其道的时代就是过时的。实践中我们往往在系统第一次建设时进行一个重型的设计过程，给系统搭建一个相对合理的架构，然后再利用敏捷方法不断迭代升级、不断完善，此时往往伴随着架构的逐渐腐化，以致于到一定阶段需要再用MDA来一次彻底的重构。而业务中台是客户企业中台战略的重要组成部分，是按照全新架构、全新思路建立的平台，正适合采用MDA这种重型的设计方法论来指导。

2  模型驱动架构方法的优点

在进行信息化系统开发时，我们面临两个突出的困难：一是如何确保设计反映业务，即如何确保我们是为了业务中台进行设计，而不是拿出一个放之四海皆准的普适的方案;二是如何确保设计意图贯彻到开发中去，即如何确保系统开发落实了设计方案。这两个问题是多数项目中非常普遍且很难解决的问题，MDA可以很好地解决这两个问题。

2.1  确保设计反映业务

MDA通过把系统分析、设计、实现的过程抽象为一系列建模过程，把非结构化的过程工件结构化，借助工具实现模型对业务的全覆盖，实现模型之间的信息交接无遗漏、不失真，且从分析到实现的全过程可追溯。

2.2  确保实现贯彻设计

MDA借助工具提供辅助代码生成功能，输出包含业务逻辑和业务规则的代码规约（即接口），这些规约规定了系统实现需要那些领域类、存在那些辅助类/接口规范，以及其业务逻辑和业务规则。开发团队借助一些工具（如Swagger），可以自动根据这个规约生成前端和后端实现代码。MDA也输出物理模型建库脚本，有些工具会基于建库脚本生成DAO层甚至前端CURD代码。

3  可行的模型序列

在业务中台实际工作中，本人提出一个MDA落地可行的模型序列，通过依次构建序列上的每个模型，描述模型中容纳的概念，在模型序列的引导下，由业务逐渐逼近系统实现，该序列如图1所示。

从业务空间到系统实现要经过四个视角的转换，称之为域，即业务域（业务流程模型、业务用例模型）、应用域（业务对象模型、领域模型）、数据域（概念模型、逻辑模型、物理模型）、技术域（组件模型）。每个域通过对一个或多个模型的建立，从不同视角描述同一个事物（即业务中台的业务）。

3.1  业务域

在业务域我们用直白的语言描述業务事实，不进行抽象。此阶段使用的工具即业务过程模型，该模型又包括业务流程模型和业务用例模型。

该阶段的核心工作是需求的结构化，即通过建立业务流程模型和业务用例模型，把从客户那里收集到的非结构化的、碎片状的需求信息结构化，用结构化数据描述业务空间，不但能确保分析人员全面描述业务，避免遗漏，而且将需求变成了数据。从需求到数据的这一转换非常关键，此举使得后续的系统分析和设计过程转变为对数据的加工处理过程，可以利用数据处理的技术进行系统分析和设计，进一步丰富了我们进行系统分析和设计的手段，为确保实现“设计反映业务、实现贯彻设计”和做到“全覆盖、无重复、无遗漏”的目标打下了基础。事实上MDA强调模型间的自动转换，需求的结构化是实现模型间自动转换的基础。

3.1.1  业务过程模型建模

业务过程建模的基本方法是切分，首先由粗到细把业务中台业务切分为业务产品、业务场景、业务单元（业务用例）、业务活动（系统用例）等不同粒度的模块，其次定义这些模块中包含的业务逻辑和业务规则，继而描述这些模块之间的关系。业务过程建模中有两个关键问题要解决：一是如何确定模块的粒度;二是如何实现业务需求的结构化描述，下文结合业务中台的实践尝试进行分析。

3.1.2  业务概念的粒度

业务模型中通过建立业务产品、业务场景、业务单元、业务活动、业务用例、系统用例等概念对业务中台的业务进行不同粒度的逐级切分，分而治之，为建立业务中台业务的结构化描述提供概念框架。既然谈起划分，就面临粒度的问题，笔者的认识是，粒度的把握取决于概念的用途，业务产品、业务场景等高层概念的划分粒度和维度必须是客户能够理解的，与客户的认知保持一致。最细粒度的概念的粒度把握最为关键，必须是可结构化的，是能够用于指导后续设计、有利于后续模型的建模复用的。在业务中台项目中，我们约定业务过程模型中最细粒度的概念是业务活动，其粒度为一次包含业务逻辑处理过程的人机交互或者系统间的交互，同时为了简化方法论的复杂度，约定系统用例等价于业务活动。

3.1.3  需求的结构化

在业务过程模型的几个业务概念中，最细一级的业务概念即业务活动最为关键，在业务中台项目中，业务需求的结构化描述主要是在业务活动中展开，UML和BPMN2.0等建模语言都为需求的结构化提供了支持。如UML的行为元素提供了规范、输入参数、返回值等项;约束元素通过Post-condition、Pre-condition、OCL等项目提供结构化手段;规则元素则通过结构性描述规范提供了对业务步骤的详细描述手段。

由于项目的时间成本限制和团队对UML的实际理解程度的原因，我们实践中在需求的结构化方面采用通俗易懂的约束+规则两种元素来结构化业务需求。

3.2  应用域

该域从功能、服务角度描述业务，用业务的语言回答怎么做，在应用域有两个模型：业务对象模型、领域模型。

3.2.1  业务对象模型的建立及其重构过程

业务过程模型给出了完整的、详细的业务需求的结构化描述，不过这种描述是面向过程的;业务对象模型则实现一个跳跃，从面向对象的视角给出业务描述，可以说业务对象模型帮助我们从面向过程的分析进入了面向对象的分析。在业务中台项目中借助建模工具和自己编写的自动化脚本（这也体现了上一阶段需求结构化的好处），实现了面向过程描述向面向对象描述的部分自动转换，同时确保业务过程模型向业务对象模型的转换过程中信息全继承、无遗漏。

3.2.1.1  业务对象的识别

业务对象包含方法和属性，其方法由业务过程模型的业务活动（或系统用例）迁移而来，其属性由业务过程模型中的输入输出信息迁移而来。对转过程可借助自动化工具自动完成。

业务对象识别的过程为：

（1）首先从业务过程模型的输入输出业务信息中抽象出业务对象，同时建立业务对象和输入输出业务信息的“血缘关系”。

（2）遍历所有与该业务对象存在“血缘关系”的输入输出业务信息，取其数据项作为业务对象的属性。

（3）遍历所有与该业务对象存在“血缘关系”的输入输出业务信息，进一步管理与这些输入输出业务信息相关联的业务活动或者系统用例，取这些业务活动或者系统用例作为该业务对象的方法。

3.2.1.2  业务对象模型的重构

通过上述三步得出业务对象的原型，然后对业务对象模型进行重构：

（1）语义分析：1）对于重复的对象，做去重处理;2）对于有共同祖先的对象，建立抽象父类，与父类之间建立泛化关系;3）对于语义有交叉的业务对象，进行拆分，根据需要定义新的业务对象或者合并业务对象。

（2）对象间关系分析：1）识别对象的聚合、组合关系;2）识别对象的依赖关系。

（3）属性和方法的语义分析：由于业务对象的属性是由有“血缘关系”的业务信息的数据项的简单合并，且在做去重处理时进一步合并了属性和方法，因此必然存在属性重复、方法重复的情况，所以需要继续对同一个业务对象内的属性、方法进行合并、去重处理，处理过程与第一步语义分析过程类似。

（4）对标处理：1）规范命名：业务对象的命名、方法的命名、输入输出参数的命名都要符合命名规范，不规范的命名要进行规范;2）分析业务实现和业务应用场景，调整不合理的定义，比如对于身份证号，要替换为证件种类和证件号码两个字段;3）与数据词典对标：业务对象的属性必须来自数据字典，即要与数据字典中的某个单词建立映射关系，其语义、值域要保持完全一致。

3.2.2  领域模型的建立及其重构过程

领域模型完全继承业务对象模型的业务对象和对象间关系等信息，并在此基础上做了以下两方面的工作。

3.2.2.1  由业务描述向功能定义转变

分析领域对象从业务对象中继承过来的行为，识别业务实现需要的功能支持，这些功能或者抽象为领域对象，或者作为领域服务存在。

3.2.2.2  识别对象之间距离关系

建立聚合，并定义聚合根、领域服务。为了简化设计，项目中约定以下内容：

（1）聚合：聚合是内聚性很高的领域对象的组合。聚合实现了对业务规则的封装，约定聚合是由具有数据一致性要求、需要变动的一组实体组成，并约定微服务的最小边界不能小于聚合（事实上一般要远大于聚合），这样的聚合能够避免分布式事务。

（2）聚合根：聚合中主要的领域对象，代表聚合对外提供访问接口，约定只有聚合根才提供有业务含义的对外接口方法，如签订合同、终止合同等，聚合中的其他实体只提供CRUD操作;在聚合之外要访问聚合只能通过访问聚合根的接口方法实现。

（3）領域对象：为了简化设计，约定领域对象等价于业务对象。

（4）领域服务：无法归于某个领域对象，是可复用、无状态的独立服务。

4  结  论

模型驱动架构方法论出了系统分析设计的全局性的、协调一致的全景视图，实现了业务需求的结构化描述，在一定程度上实现了计算机辅助系统的分析和设计。某大型央企业务中台建设的实践证明该方法论是完全可以落地的，其能够确保每一项设计都有依据、每一个结论都可追溯，能够确保设计成果反映业务，确保设计成果贯彻落实，从而让客户更有可能获得他们真正需要的系统，是一种非常有价值的系统分析和设计方法。

参考文献：

[1] 张鹏，李忠民.企业级数据模型全域一致性的一种解决方案 [J].智库时代，2018（35）：135-136+139.

[2] FRANKEL D S.应用MDA [M].鲍志云，译.北京：人民邮电出版社，2003.

[3] KLEPPE A，WARMER J，BAST W.解析MDA [M].鲍志云，译.北京：人民邮电出版社，2004.

作者简介：李忠民（1967—），男，汉族，山东聊城人，技术专家，中级职称，本科，研究方向：银行应用系统设计开发、大型互联网平台架构设计、大数据应用系统设计;何鑫（1988—），男，汉族，内蒙古乌兰察布人，助理工程师，本科，研究方向：国网公司统一数据模型（SG-CIM）设计。