DDD领域驱动设计实战-服务和数据在微服务各层协作的最佳实践

微服务间的应用服务可直接访问，也可通过API网关。由于跨微服务操作，在进行数据新增和修改操作时，注意保证数据一致性。

领域事件驱动

领域事件驱动包括微服务内和微服务之间的事件。微服务内通过事件总线完成聚合之间的异步处理。微服务之间通过MQ完成。异步化的领域事件驱动机制是一种间接的服务访问方式。

当应用服务业务逻辑处理完成后，如果发生领域事件，可调用事件发布服务，完成事件发布。

当接收到订阅的主题数据时，事件订阅服务会调用事件处理领域服务，完成进一步的业务操作。

服务的封装与组合

---

• 微服务的服务是从领域层逐级向上封装、组合和暴露

基础层

服务形态主要是仓储服务。仓储服务包括接口和实现：

• 仓储接口服务供应用层或领域层服务调用

• 仓储实现服务，完成领域对象的持久化或数据初始化

领域层

领域层实现核心业务逻辑，负责表达领域模型业务概念、业务状态和业务规则。主要的服务形态有实体方法和领域服务。

实体采用充血模型，在实体类内部实现实体相关的所有业务逻辑，实现的形式是实体类中的方法。

实体是微服务的原子业务逻辑单元。在设计时我们主要考虑实体自身的属性和业务行为，实现领域模型的核心基础能力。不必过多考虑外部操作和业务流程，这样才能保证领域模型的稳定性。

业务规则和逻辑校验在领域层。

DDD提倡富领域模型，尽量将业务逻辑归属到实体对象，实在无法归属的部分则设计成领域服务。领域服务会对多个实体或实体方法进行组装和编排，实现跨多个实体的复杂核心业务逻辑。

对于严格分层架构，如果单个实体的方法需要对应用层暴露，则需要通过领域服务封装后才能暴露给应用服务。

应用层

表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，负责不同聚合之间的服务和数据协调，负责微服务之间的事件发布和订阅。

通过应用服务对外暴露微服务的内部功能，这样就可以隐藏领域层核心业务逻辑的复杂性以及内部实现机制。

应用层的主要服务形态有：

• 应用服务

• 事件发布

• 订阅服务