最后对应到真实发生的数据实体上，如下图：梳理完所有的业务流程、业务实体、数据实体后可以将对象作出根据不同业务域的清晰的层级划分，如下图：最终形成完整统一的轨道运维概念数据模型，如下图：可以看出，这是一个完整的从具体到抽象的高度提炼概括的过程，整个过程紧密贴合实际业务，全面客观地对应业务实体和业务对象，最终实现数据对业务的准确映射。上述这个过程也是我们对象定义和建模、组件定义和分级、模型定义和分级的核心依据！例如我们对“钢轨”这个实体对象做建模，通过9个逻辑维度、63个逻辑要素做好元数据定义和约束，并形成关于“钢轨”这个对象组件，由此来支撑所有需要“钢轨”这个组件的领域模型建设。而“钢轨”、“焊缝”、“扣件”、“轨枕”、“道床”、“道岔”、“伸缩调节器”、“接触轨”、“轨道附属设施”等所有的对象完成建模和组件化后就可以完成“基础设备信息”这一业务域的局部领域模型建设，这个模型对应的就是数据模型中的一级主题域，也可以对应业务模型中的一级业务域。而所有的局部领域模型建设完成，就可以实现针对全业务的领域模型。对象、组件和模型其实都是有层级的，是必须严谨对应到业务上的，也只有这样的严谨，才能将业务中那些最难发现的、隐藏在实际业务中的业务逻辑和业务规则完整继承下来。并且，这种分析和梳理的过程，也是对IT核心资产的完整继承。IT的核心资产，其实应该是现有系统中已经在运行、并证明对业务有真实支撑能力的业务模型和数据模型，而上述解耦和封装的过程，是完全基于对业务模型和数据模型科学严谨的学习和理解的过程。以上是方法论思想的论述，更为技术角度的解读是从平台业务系统的逻辑模型到物理模型的直接映射为造成问题的主要因素来出发的。既然物理模型的变更是平台不稳定的动因，那么我们是否能通过解耦业务逻辑模型和物理模型的映射关系来尝试解决这个问题呢？基于上述的事例，我们需要对业务进行建模，对业务进行抽象，定义出业务逻辑模型，然后对模型进行二次抽象，定义出逻辑模型的定义数据，实现业务模型的数据化，即模型的元数据(The Metadata of the Logic Model)，将模型结构存储为数据，而不是直接对应的物理存储结构。其次根据定义出的元数据进行统一抽象，形成元数据逻辑模型。将元数据逻辑模型映射到元数据物理模型，对应实际存储结构。通过对业务模型的变更形成对元数据层的数据变更，而不是物理结构的变更，从而实现业务逻辑模型同物理模型的解耦。当然反过来，由于纵向功能细分，业务功能域增多，整个业务链条上的咬合点越来越多，于是，可以得出的结论是，最小业务组件颗粒其实就是描述最小业务实体所对应的业务对象，而组件要素就是描述最小业务对象所对应的元数据！而将该元数据所对应的所有业务逻辑要素（属性和规则等）同业务对象一起做好封装就形成了最小业务单元组件！这其实就是传统的业务逻辑模型的实现过程的组件化。将某一业务域所有业务组件做有机整合，结合流程模型、报表模型、页面模型和集成模型等，就完整了一个业务流、信息流和数据流三流合一的领域模型！所以，领域模型其实就是真实反应业务应用的物理模型。本文试图第一次详细准确的描述对象、组件和模型之间的定义和关系。这三者是整个低代码PaaS平台最为核心的概念之一。对于正在考虑重构的业务系统而言，对于既有IT资产中最为核心的业务模型和数据模型的继承就是采取上述的梳理方法，然后通过低代码做好对象建模的整体设计工作，这样的重构才是严谨规范的，是成功交付的保障。对于新建业务系统而言，上述过程其实就是新一代敏捷开发的全部基础。敏捷开发绝不仅仅是简单的迭代，我们认为敏捷开发是在完成领域模型后的搭建过程，而其核心基础对业务的解耦和组件化的工程。
沪公网安备 31011802004687号
