【DDD】学习笔记-领域服务

聚合的三个问题

按照面向对象设计原则，需要将“数据与行为封装在一起”，避免将领域模型对象设计为贫血对象。如此一来，聚合内的实体与值对象承担了与其数据相关的领域行为逻辑。聚合满足了领域概念的完整性、独立性与不变量，体现了聚合才是对象粒度之上自治单元的最佳选择。一个设计良好的聚合同样需要做到最小完备、自我履行、稳定空间和独立进化。

在领域驱动设计中，自治对象参与了聚合内部的协作，而聚合作为多个实体与值对象的整体，则是参与业务场景的自治单元。倘若将聚合拥有的数据称为“已知数据”，若一个业务场景的领域行为只需操作这些已知数据，就应定义为聚合内相关类的领域方法，倘若该领域行为还需要和别的聚合协作，该方法就被分配给聚合根实体。有时候，聚合的已知数据并不足以支持整个业务场景的领域需求，为了保证聚合的自治性，会将不足的部分通过聚合方法的参数传入。通过参数传入的外部数据皆可视为聚合的“未知数据”。

为了彰显聚合边界的防御作用，聚合并不会直接与别的聚合协作，那么这些未知数据从何而来？

聚合封装了多个实体和值对象，聚合根是访问聚合的唯一入口。若要遵循迪米特法则，聚合调用者应该只需知道暴露在外的聚合根实体，当业务需求需要调用聚合内实体或值对象的方法时，聚合当隐去其细节，由根实体包装这些方法，在方法内部的实现中，将外部的请求委派给内部的相应类。封装的领域行为被固化在聚合之中，成为了聚合的附庸。这是将对象作为一等公民的面向对象设计思想的体现。

在业务系统中，总会有一些领域行为游离在聚合之外，它们要么不需要聚合自身携带的已知数据，要么存在与聚合迥然不同的变化方向，这些领域行为应该附庸在哪个对象之上呢&