关于领域模型的一些零散概念

前言

一提到领域驱动开发DDD就离不开面向对象和面向过程，面向对象本质是对象与行为绑定，面向过程则是一种指令式的，每个过程处理来自表现层的单个请求。正好今天培训老师讲到了一些关于领域驱动开发的东西，记录在这跟大家一起分享一下。

为什么进行领域驱动开发

可复用可维护，易扩展，模块化、可扩展、易于维护的，同时设计还反映了业务模型。提高了业务领域对象的可重用性和可测试性。
业务人员和设计人员共同参与。不以人为中心，更客观的体现业务价值。
领域模型具自己的属性和行为状态，并与现实世界的业务对象相映射各类具备明确的职责划分，领域对象元素之间通过聚合和引用等关系配合解决实际业本应用和规则。
可以采用合适的设计模型进行详细设计，同时要求设计人员有良好的抽象能力

事务脚本

说起领域模型之前要先说一下相对应的一个概念，这就是事务脚本。事物脚本的核心是过程，每个过程处理来自表现层的单个请求。事务脚本更接近与过程，给机器执行，人工维护困难，而面向对象（对现实世界的映射）而更易于理解。

具体体现：系统围绕数据库来处理，事物脚本（controller，service比较轻，dao比较重）

领域对象什么样

一个典型的领域模型如下图所示：

下面就以一个转账的服务为例子来对比一下两种模型的特点：

首先是事务脚本，事务脚本的模型如下图所示：

绕后是，领域模型的方式

里面有策略模式的影子，扩展性较强

但是比较复杂，包含了状态

特性

领域对象与现实世界的业务映射

明确的职责划分

复用性较高

易于理解

完整的业务对象描述

使用场景

复杂业务逻辑的软件开发

对设计和开开发人员要求较高

不适用简单的CRUD的业务

软件的维护性和扩展性较好

几种模型

失血模型：一版的开发方式，service中包含逻辑而模型中没有逻辑

贫血模型：不依赖与持久化，加入一些逻辑

充血模型：绝大多数业务逻辑都在DO里

涨血模型：没有Service，C++中较为常见

原则：业务对象封装了内在的业务逻辑，而应用服务（service）封装了外在业务对象的业务逻辑

总结

领域模型更加适合体现现实世界的本质属性，所以当业务领域非常复杂时领域模型是非常合适的，但同时领域模型对于设计人员的技术能力提出了更高的要求。所以我们一般的业务系统开发很难看到领域模型的影子。