领域驱动设计基本概念答疑

问题： DDD实现中领域对象区分实体(Entity)和值对象(Value Object)的目的(Why)是什么?或者换一种问法：领域对象区分实体(Entity)和值对象(Value Object)之后，带来的好处和收益是什么?

回答： 从DDD的概念上讲，实体（Entity）与值对象（Value Object）的本质区别仅在于后者无需identity（唯一标识）。这其实就是带来的价值——就是你设计的对象不需要去跟踪和管理这个唯一标识。

这是概念划分上，值对象带来的价值。

再来说设计层面。通常情况下，我们建议将值对象设计成一个不变（Immutable）对象。当一个对象是不变的时，你就基本不需要担心并发带来的诸如同步、冲突等问题了，这既降低了编程的难度，又可以无需引入额外的同步锁影响程序的性能。

反而过来说，之所以可以将值对象设计成不变的，其根本原因还是在于我们无需跟踪和管理唯一标识。

在领域驱动设计中，我们提倡的实践是尽量定义值对象来替代基本类型，原因在于基本类型无法体现统一语言中的领域概念。此外，在多数语言中，我们无法对基本类型做封装，就意味着一个领域概念缺乏领域行为来支持。假设一个实体定义了许多属性，如果这些属性都是基本类型，就会导致与这些属性相关的领域行为都要放到实体中，导致实体的职责变得不够单一。

引入值对象后，情况就不同了，因为我们可以利用合理的职责分配，将这些职责（领域行为）按照内聚性分配到各个值对象中，这个领域模型就能变得协作良好。

当然，反过来说，之所以可以这样设计，还是在于值对象无需承担跟踪和管理唯一标识的职责。

这也是为何Eric要将实体和值对象分开的主要原因，也是值对象给我们带来的价值所在。

问题： Repository与DAO其实都是两种模式的名称。然而在领域驱动设计中，名称本身就是非常重要的。Dao即Data Access Object，即数据访问对象。从其命名上看，就应该属于数据访问层，即DDD中的基础设施层。

回答： 在DDD中，所有的领域对象应该都属于领域层。那么，该如何访问这些领域对象呢？DDD希望解除领域层与基础设施层之间的关系，即将设计的注意力完全放在领域建模和领域设计上，思考领域逻辑的实现时，应尽可能地不要考虑领域对象的持久化（数据访问），于是就定义了Repository这个抽象。无论放在哪里（文件、DB或者内存），Repository都将其视为一个“资源库”的抽象。经过这么一层的抽象之后，获取领域对象，或者说管理领域对象生命周期的逻辑就应该属于领域层。

在实现上，你当然可以将这样的Repository接口命名为DAO，这本身没有问题，但名不正则言不顺，如果在领域层中夹杂了一个名为DAO的接口，仍然有“将基础设施混入领域层”的嫌疑。

所以，Repository是抽象，代表了对领域对象生命周期的管理，但并不等于是持久化，持久化只是Repository的其中一种实现。你可以假设一台服务器无比的强大，内存大且永远不会宕机，这时何须持久化呢？但无论怎么修改生命周期的具体管理方式，都不会影响到Repository的抽象。