前面说到了DDD要关注领域划分、构建领域模型，但是不是所有的领域都是等价的，比如会区分核心域、支撑域、通用域，我们要重点关注的是核心域，同时每个领域的模型的复杂性也是不相同的，有些模型包含复杂逻辑而有些仅仅管理数据，DDD强调的是管理复杂性。所以不同的模型有不同的适合实现的方式，要结合实际情况最终确定。
DDD的四层架构图如下，这个图后面会不断的细化，这里先简单了解一下，可见领域层的代码只是其中一小部分。
DDD四层架构.png
-
领域模型
概念有点混乱，这里的领域模型是领域模型的实现方式，得区分一下。它是面向对象模型，包含了行为和数据。初看起来它似乎和反映了数据存储的结构，比如可能看起来和一个数据表的字段完全对应，它设计之初是忽略数据库的存在的，要从代码模型开始考虑，不能从数据模型开始思考问题（传统的开发模式一般都是先考虑数据表的字段和关联关系，然后再考虑业务逻辑），建模时专注领域问题的动作和操作，而非状态，否则可能最终产生的是数据模型的面向对象表现形式。
- 优点：代码更能充分的反映领域业务逻辑，实现了分析模型、领域模型、代码模型一致性和协调性。
- 缺点：实施成本高，需要开发人员熟练掌握面向对象，具有非常强的挑战性。
- 适用场景：复杂的核心领域，其他的简单的CURD业务场景，数据逻辑简单并且只是数据展示，不要采用，否则会造成不必要的复杂性。
-
事务脚本
这个做法是把业务逻辑都放在一个方法内，方法内部以面向过程的形式调用不同的数据处理函数（CURD）完成业务操作，很久以前很多PHP的项目有这么做的，方法内部就是直接写SQL语句，后面用了框架后只是不写原生SQL了，用了框架提供的模型，本质还是一样的。
- 优点：简单易于理解，新来的开发人员不需要特别学习领域知识，维护新功能方便。
- 缺点：业务变的复杂时，代码方法会过度重复、工作流重复无法避免，难以控制管理，后期可以朝着领域模型方向重构。
- 适用场景：不具备面向对象的初级开发团队，简单的业务模式。
-
表模块
将单个模型映射到数据库模型，一个对象表示数据库里面的一个表或者视图，完成对应的数据持久化操作。
- 优点：对象模型和数据库模型之间不会不匹配，比领域模型更易于掌握。
- 缺点: 对象模型和数据库模型可能出现分歧，比如有些字段在对象模型里有，但是在数据库里面没有，这个时候可以考虑朝着领域模型方向重构。
- 适用场景：数据库驱动设计
-
活动记录
是表模块模式的一个变体，一个对象表示的是数据表里面的一个瞬时状态或者待修改状态的数据，而不是数据表本身，每个对象都负责自己的持久化和相关业务逻辑，包括创建。
- 优点：简单易于理解，容易使用代码生成工具生成对应的代码。
- 缺点：适用场景有限
- 适用场景：非常适合数据模型和业务模型存在一对一简单映射的业务，比如博客、论坛。以前的公司创投相关的业务也是用了这样的设计。
-
贫血模型
和领域模型模式的区别在于，这里的创建的对象没有包含行为，只包含了数据。
- 优点：
- 缺点：违背了
只说不问的原则，就是应该告诉被调用方信息，而不是暴露公开属性，让被调用方自己判断。 - 适用场景：领域模型逻辑少、开发团队适用面向对象技术不熟悉，可以作为尝试创建领域模型的开端。
如果是复杂的业务场景，我们应该考虑第一种领域模型方式，也就是DDD特有的，但是简单的业务没有必要用，否则只会徒增麻烦。
网友评论