动态领域模型漫谈--领域模型服务部产品设计师：李松

今天邀请领域模型服务部的李松老师在学习营进行关于动态领域模型的互动问答，本贴记录下过程。

---

李松老师：

关于动态领域模型的解释

首先我们理解一下什么是模型？

我们开发的软件产品其实并没有创造新的东西，只不过是数字世界的传承者，计算机系统中合乎逻辑的过程，停电后人肉使用纸和笔一样合乎逻辑，合乎现实世界的逻辑和和规则，使用鼠标和键盘代替纸和笔，就是软件设计的基本逻辑。

业务领域中，如财务、电商、供应链、组织架构、仓储，这些都是各个领域实实在在发生的事情，通过我们分析业务逻辑，从中找出可固定的模式，抽象成计算机系统中对象并存储，这样的对象就是模型，如果到某个业务领域了，就叫领域模型。

那么什么是动态呢？

动态其实是运行时概念，重点是在运行时的动态，那么动态我们可以简单理解为，在运行时调整模型，页面渲染与逻辑运行也随之变化了。

合成一句话：可以按照一定的规则设计业务在计算机世界的模型，然后有一套机制可以动态渲染变化，运行变化。

当然真正的领域模型还有更多的东西，比如：

1、怎么定义这个模型（规范）？ 元元模型

2、构建模型有什么要素？元模型

3、怎么快速构建模型？ 业务模板、系统模板 

4、我们构建出来的对象是啥？ 业务模型

3、怎么实现业务扩展？扩展与继承模型，这里有一个技术叫差量运算。

提问：

松哥，关于动态领域模型，在实际的开发过程中有没有什么经验指导。比如现在要开发一套财务系统，那么我如何基于动态领域模型进行建模，一般的整体设计步骤是什么样子的，使用动态领域模型的优势比传统开发又有什么不同。

李松老师：

动态领域模型有两大特点：沉淀与复用

在我们实际开发过程中，我理解我们要注重模型抽象能力

而领域模型驱动下，我们要具备一定的抽象思维，举个例子，比如我们销售行业中，订单、库存、商品这些概念，其实是基本稳定的，无论你是电商行业、还是传统销售行业或者说新零售行业，这些都不会变化或者变化极小。

在财务领域也相同，科目、凭证、银行账号，这些无论是在财务共享、传统财务，这些一直都是在的。

基于领域模型建模，设计步骤我的建议是：先去抽象模型，模型可以分为 跟业务直接相关的业务实体模型（业务本身的实体结构），以及与业务相关的业务逻辑模型（业务相关的运算模型，比如额度模型、核销模型、结算模型等等）

再结合商业场景，做出相应的布局。

在传统开发一般不太注重模型抽象能力，可能是来一个页面做一个，当整个市场背景变化了，我们可能要从底层还是重构改造。

而领域模型驱动的，则依然保持着业务模型不变，变化的只是使用终端的布局、业务流的组合以及部分组合逻辑。

提问：

动态领域模型和数据模型有什么区别呢？

李松老师：

这里纠正一下，动态领域模型是理念不是一个模型。

你想说的应该是实体模型和数据模型的区别。

数据模型，描述了数据表最原始的组成 字段（这里可能就是int、string、bool这些）、属性（这里可能只是必录、长度、精度这些）

而实体模型模型 已经进阶到业务层面，他不但包含了组成（组成也是有业务含义的字段，比如金额、物料等等）还包括了部分核心逻辑。

通俗一点，数据模型我们只能看我们存储了什么，实体模型是可以不要界面独立运行的，可以承载业务的。

提问：

松哥，关于动态领域模型在苍穹中的应用，映射到系统中的动作就是我们先基于业务抽象，然后构建实体模型，再配置业务规则等，然后上层创建布局，这样系统天然的就把实体，逻辑，页面分层了，后续随着业务发展，哪一层有改动不会影响到其他层的模型，这些每层的模型也都支持差量化叠加，便于不同角色在不同场景进行调整，整个结构是这样的吧

李松老师：

是的。

提问：

ok，那新版的开发平台的操作确实更容易理解到这里。平台提供的元元模型，包括各种组件、模型容器、规则。操作等，伙伴可以基于这些元元模型来组装构建自己的元模型，就是改造现在的单据基础资料这些模型。现在还提供模型扩展，可以扩展这些元元模型，包括组件，属性，规则，操作等，满足目前平台不支持的底层模型逻辑。

李松老师：

动态领域模型由动态表单、元数据和元模型组成，这里其实有三个概念。
元数据是描述语言。
元模型是构成方式。
动态表单是运行方式。

从模型角度，从上往下。
企业模型（这个其实是行业模型，在领域模型上扩展出了一些行业属性。）
领域模型（领域模型，就是通过这些元模型构建的业务模型）
元模型（这里个就是你理解元素、属性、操作等等东西）
元元模型（这个是一个套规范，类似于java里面语法，也就是你的元模型也好领域模型也好，必须是依据我这个规范来做）

从业务逻辑构成来说， 可以分为实体模型、布局模型。
但从业务划分来说，又可以做很多其他，比如基础资料模型、预警模型等等，这些模型也是有实体逻辑和界面的。

要从多个维度去看，划分也就不一样了。

新版开发平台的主要改进点，是建模过程的优化。从抽象实体开始，到具象的页面。
老版的是反着的，先有具象的页面，由系统反推出实体，这样有优点，很快，很方便。
但忽略了一个问题，因为太具象的内容，往往不具备抽象性，有点像传统开发，老版我认为我们的重点在快速构建，有点类似于以前我们用的快速开发平台（像.net这样的拖拉拽快速生成）。
现有一个概念叫低代码开发平台，和快速开发平台的本质区别就是模型驱动，模型是企业业务沉淀。

提问：

我的理解建立模型，或者说就是建立一个框架、标准，所有的逻辑，都必须基于这个模型来进行。这个模型对应到开发语言来讲，就可以是我们面向对象的一种逻辑，从base模型，到runtime的结果，是不断丰满的一个过程。最后渲染画面的时候，会将模型的不同状态绘制到界面上，并给予对应的操作。

领域模型到元模型再到元元模型，那么其实就是不断填充重构的一个过程，也就相当于我们在开发时不断使用了种种设计模式去构建一个最终运行的系统，针对于产品来说，在迭代开发方面确实有很好的效果。但同时问题也来了，模型的建立是为了长期的构建，而我们设计场景的时候，或者在业务领域去构建模型的时候，很多情况下，我们并不能把控一个业务字段的实际使用类型。

举个很简单的例子，比如说，签章模式，最早只有线下盖章这一种方式，随着社会的发展，我会出现到智能印控和电子签章。那么最早，我会设计成，是否使用电子签章，对于早期的场景场景，我只需要考虑线下，再到线下和智能印控两种场景，再现在就是三种场景。那么未来，也可能出现更多的场景，但我们在设计模型的时候，并不会完全考虑到所有的场景，如果是一种场景变为两种场景，我们扩展只需要增加一个复选框字段，如果是从两种场景变为三种场景，我们就需要添加下拉框字段，如果从三种场景变为多种动态场景，就可能变成基础资料。

在不断的扩展不断的修改设计模型，这里又有什么更好的办法去解决这个问题还不影响已有模型的界面显示？

李松老师：

首先模型也不是绝对稳定的，是允许变化，我们所需要保证的也只能将改动降低到最低。
但是你刚才的场景应该是可以避免的，电子签章以前可能是挂附件，现在我可以通过影像和电子签章来处理，但对于合同这个主题来说，签名这个字段，无论是采用什么方式都这样需要的，只是我采集的方式变化。
有些场景跟当时设计有关系，可能会一旦处理不好就会要求全部都改。