解读《领域驱动设计 软件核心复杂性应对之道》（二）

      DDD的理念是一种理想化的思维方式。在项目落地的时候，还要参考目前已成型的框架的支持情况。说白了，就是理想很丰满，现实很骨感。鉴于目前技术框架的限制，我们在做DDD设计时，不得不在一些地方做出一些细微的取舍。

       下面继续来解读这本书。

      第六章 领域对象的生命周期

       上章讲到了领域驱动设计中的构造块。构造块中，非常重要的两个就是ENTITY和VALUE OBJECT。生命周期这个概念在软件行业非常常见，就是指的是从诞生到消亡的整个过程。本章题目是领域对象的生命周期。但实际上，作者更多的只是在谈ENTITY和VALUE OBJEC的生命周期。大家都知道设计模式中，有个模式叫做工厂模式FACTORY。领域驱动中的这些领域对象也是建议通过工厂模式创建出来。创建出来的领域对象，有可能需要存储到数据库，或者存储到其他位置，比如文件服务器。这时候就要用到另外一个模式:REPOSITORY。REPOSITORY模式要求程序隔离数据存储的细节，领域层只需要与REPOSITORY交互。这样不管数据是存储在对象数据库中，还是存储在关系数据库中，或者简单地保持在内存中，客户代码都是相同的。REPOSITORY和FACTORY本身并不是领域对象，按照作者的话说，二者在领域驱动设计中扮演着重要的角色。

         我们应该将ENTITY和VALUE OBJEC分门别类的聚集到AGGREGATE中，并选择一个ENTITY 作为根。各个AGGREGATE之间，通过聚合根进行数据交互。不能绕过聚合根修改内部对象。这样能够保证AGGREGATE之内数据逻辑的一致性(比如，删除了一