关于ddd聚合设计的问题？领域层与基础层为什么要依赖倒置（DIP）？

聚合主要实现核心业务逻辑，里面有很多的领域对象，这些领域对象之间需要通过聚合根进行统一的管理，以确保数据的一致性。

在聚合设计时，我们会用到两个重要的设计模式：工厂（Factory）模式和仓储（Repository）模式。如果你有兴趣详细了解的话，推荐你阅读《实现领域驱动设计》一书的第11章和第12章。

那为什么要引入工厂模式呢？

这是因为有些聚合内可能含有非常多的实体和值对象，我们需要确保聚合根以及所有被依赖的对象实例同时被创建。如果都通过聚合根来构造，将会非常复杂。因此我们可以通过工厂模式来封装复杂对象的创建过程，但并不是所有对象的构造都需要用到工厂，如果构造过程不复杂，只是单一对象的构造，你用简单的构造方法就足够了。

又为什么要引入仓储模式？解答这个问题的同时，我也一起将依赖倒置的问题解答一下。

在传统的DDD四层架构中，所有层都是依赖基础层的。这样做有什么不好的地方呢？如果应用逻辑对基础层依赖太大的话，基础层中与资源有关的代码可能会渗透到应用逻辑中。而现在技术组件的更新频率是很快的，一旦出现基础组件的变更，且基础组件的代码被带入到了应用逻辑中，这样会对上层的应用逻辑产生致命的影响。

为了解耦应用逻辑和基础资源，在基础层和上层应用逻辑之间会增加一层，这一层就是仓储层。一个聚合对应一个仓储，仓储实现聚合内数据的持久化。聚合内的应用逻辑通过接口来访问基础资源，仓储实现在基础层实现。这样应用逻辑和基础资源的实现逻辑是分离的。如果变更基础资源组件，只需要替换仓储实现就可以了，不会对应用逻辑产生太大的影响，这样就实现了应用逻辑与基础资源的解耦，也就实现了依赖倒置。

关于聚合设计过程中的一些原则问题。大部分的业务场景我们都可以通过事件风暴，找到聚合根，建立聚合，划分限界上下文，建立领域模型。但也有部分场景，比如数据计算、统计以及批处理业务场景，所有的实体都是独立无关联的，找不到聚合根，也无法建立领域模型。但是它们之间的业务关系是非常紧密的，在业务上是高内聚的。我们也可以将这类场景作为一个聚合处理，除了不考虑聚合根的设计方法外，其它诸如DDD分层架构相关的设计方法都是可以采用的。

一些业务场景，如果复杂度并不高，而用DDD设计会带来不必要的麻烦的话，比如增加复杂度，有些原则也是可以突破的，不要为做DDD而做DDD。即使采用传统的方式也是没有关系的，最终以解决实际问题为最佳。但必须记住一点，如果采用传统的设计方式，一定要保证领域模型的边界以及微服务内聚合的逻辑边界清晰，这样的话，以后微服务的演进就不会太复杂。