如何对MIS系统快速进行分析设计-领域驱动设计实践

Eric Evans 编著的《领域驱动设计》一书从2003年出版以来已经有很多年了，作者写这本书的目的是指导程序员如何对系统进行分析设计，将业务概念抽象为领域知识，这种抽象出来的模型能够很好的和客户进行“沟通”。通过领域驱动设计的思想，软件开发人员能够应用面写对象的思想和UML（统一建模语言）描述业务。软件“建模”成为了同建筑设计图纸类似的东西，而不是某个程序员画出的数据库表结构和一大段文字描述。

       虽说领域驱动设计（以后简称DDD）说起来是很有价值，但是里面包含的诸多概念，如“限界上下文“、”聚合根“、”仓储“等等，如何在我们通常的业务系统中应用感觉有些摸不到头脑，笔者针对MIS类系统结合自己多年的实践提一下自己的看法。

      

业务系统的拆分

       在传统的业务系统开发过程中，我们一般把一个复杂的业务系统拆分为模块，例如：系统管理、销售管理、采购管理等等。那么更进一步的划分呢？而在DDD中，有个概念叫做“限界上下文“，书上的解释是：是一个显示边界，领域模型即存在于这个边界之内。在边界内，通用语言有特定明确的意义。还举了个例子：细胞膜把细胞内部和外部区分开来，而且还能决定通过的物质。这是什么意思？DDD中还有一个推荐的六边形架构：

       通过上面描述和架构图，我们可以看到，“限界上下文“内部包含了领域模型，还对外提供了适配器，也可以叫做服务，和目前互联网很流行的”微服务“非常类似。但这个”限界上下文“的名词太抽象了，说出去估计很多人都一头雾水，我更想将它命名为”业务组件“，OMG（对象管理组织）在建模语言规范中将组件定义为：“系统中一种物理的、可代替的部件、它封装了实现并提供了一系列可用的接口。一个组件代表一个系统中实现的物理部分，包括软件代码（源代码，二进制代码，可执行代码）或者一些类似内容，如脚本或者命令文件。我觉得上述描述还是很接近”限界上下文“的内容的，适配器相当于接口。

       所以，业务系统可以拆分为模块、组件两层，组件可以单独部署，对应于目前的微服务。

组件

       我们怎么划分一个组件呢？按照“限界上下文“的说法，当然要按照业务，具体要怎么做呢？我们根据业务建立领域模型后，就需要划分为更小的业务组件，每个业务组件会包含1到多个实体和服务，这些实体和服务应该是联系比较紧密的，例如：销售订单和订单行联系就很紧密，订货相关服务与销售订单和订单行就不可分割，它们就组成销售订单组件；同样发货单也是如此。

最简单的划分方法，按笔者的经验，每一种业务单据都有可能成为一个组件，例如：采购订单、入库单、生产订单，但是不要分得太细，例如：固定资产采购订单和低值易耗品采购订单，这些采购订单的细分类别应该成为采购订单上的一个采购类型属性，而不是成为一个新的组件；第二，每种基础档案都有可能成为一个组件，例如：物料档案、仓库、销售价格表、计量单位等等，但是要注意，某些档案之间联系非常紧密，可以放在一个组件内，例如：仓库和库位，它们共同表示一个位置；计量单位组和计量单位；很多规则性的东西往往会依附在某个基础档案组件，例如：销售价格策略可以放在销售价格表中，取计量单位间转换率规则可以放在计量单位组件中。

组件内又包含什么呢？除了适配器（组件接口）外，内部的领域模型具体是什么呢？见下图。

       在软件开发中，业务逻辑层和数据访问层一般都会分离，实体代表数据层，所以从实现的角度，而业务逻辑层往往是接口和实现分离，又可以这样划分：

       表示层放在哪呢？在WEB应用中，表示层一般指HTML/JSP/ASP等等在浏览器端展现给用户显示内容的部分，按笔者的想法，表示层也应该是组件的一部分，因为它们脱离不了适配器和领域模型，例如：销售订单的订货页面能离开后面的数据吗？后台的数据结构发生变化，订货页面也会随之改变。

       如果是一个复杂的统计报表呢？例如：销售库存统计表，笔者认为这个统计表不属于销售订单组件，应该在销售模块下新建一个销售统计组件。

       所以，按照上面的构想，新的组件模型应该如下：

实体

       在DDD一书中，“以标识作为其基本定义的对象称为实体“。也就是说，实体有唯一标识，就像每个人有身份证号一样，每一样物体都有一个唯一标识，那么在信息系统里，怎么简单的表示呢？笔者建议使用xxID作为每个实体的标识。

       在信息系统中，经常有档案、单据实体，可以将这些作为实体的类型。另外，DDD中有一种聚合根（Aggregate Root）实体，我们将它们命名为“主实体“，主实体聚合的实体叫做”子实体“，一个组件内可以包括1到多个主实体及多个子实体。主实体在维护的时候，一般是和其子实体一起进行的，例如：新增一张销售订单时，订单头和订单行一般是输入完毕后一块提交保存的，子实体的生命周期是由主实体决定的。

值对象

       值对象是用于数据传递的，是在内存中的快照，断开系统后就会丢失。笔者认为在信息系统中，值对象可以分为两类，一种是服务传递用，一般是实体的一部分，例如：新增一个实体，传递的参数对象就是，笔者命名为DTO（数据传输对象），第二种是表示层显示需要，例如，显示一张订单，我们在保存这张订单时，关联数据保存的往往时实体的ID，例如：客户ID、物料ID，但是在显示这张订单时，ID是没有意义的，需要显示的是客户名称、物料名称、计量单位名称等等，所以表示层需要的值对象是一种将多个实体数据关联起来的对象，笔者命名为View（视图对象）。

服务

       分为基础层和应用层，基础层实现增删改查，应用层实现业务逻辑

表单

       根据笔者多年信息化系统开发的经验，前端页面是有一定规律的，对于信息化系统，大多数都是一些档案和单据，所以档案和单据的维护占据了大部分页面，所以按照这些页面，笔者设置了表单类型：列表、新增对话框、修改对话框、维护页面（针对单据）、新增子对话框（针对子实体）、修改子对话框、其它。

       每个单据由多个部分组成（WebPart），每个部分由工具条（可选）和字段组成，WebPart分为两种，一种是Panel面板，一种是Grid列表。通过拖拽方式可以进行维护。

       笔者根据上面分析，实现了鸿图软件开发平台，网址：www.htplatform.cn ，欢迎大家使用参考。