领域驱动设计-软件核心复杂应对之道--模式设计

模式设计篇，主要针对ddd的几个重要概念进行了定义

主要分为entity/value object/service/module

 

Entity:(又称为reference object)

引言：房东出租房坏了，起诉作者，其实是另外一个同名同姓的人。隐喻：如何区分一个对象

Entity 需要有一个标识定义，在生命周期内是连续的，而且不随自身熟悉的变化而变化。说白了，需要一个唯一标识。

Entity 建模的基本原则是，确保连续性，保持实体的简练，不要过多关注的属性和行为上。

唯一标识的生成，例如jvm进程中的内存地址、分布式环境的唯一ID、数据库的自增ID等。

 

Value Object(值对象)

引言：2个小孩画画，他只关心用什么颜色、粗细的笔来画，画好后，他不用关系某个图上的细节是什么笔画的。如果需要关系，这会非常复杂。

 

值对象：不可变对象，常量

需要考虑2个场景，复制和共享：（如：同一个jvm中，共享合适，分布式场景，复制合适）

最好使用共享的场景：

1：节省数据库空间是一个性能关键点的时候

2：通信开销很低的时候

3：共享的对象被严格定义为不可变的时候

 

Service

有时候，一些从概念上不知道该归位哪一类事物的时候，经常会引用到Service上

特点：动词

Bad Case:

1：没有为一些行为找到合适的对象，service的实现慢慢变成过程型代码

2：一些service常常以对象（类）的形式存在，做一些没有领域意义的事情，常常以-Manager结尾

3：替换entity或者value object的某些职责

 

Good Case:

1：与领域模型的操作，不是entity 或者值对象的某一部分（不会越权）

2：接口根据领域语义定义

3：无状态的

 

Ps:应用层和基础设施层，是可以有部分无领域意义的service。

 

Module(package)

module直观好处有2个，一个是在module中不会被细节淹没、另外是可以直观查看module之间的依赖关系

通用设计原则：高内聚，低耦合。划分上可以是代码的分类、领域概念的分类。

命名应该以领域语义命名，反应领域的抽象知识

敏捷module,建议将单一概念对象的所有代码打包在一起，原因有2点，

一个是代码散落在不同包里面，无法清晰表达模型

一个是人类的大脑还原能力有限，比较难关联多个不同的mudule