关于ddd:CQRS在一条订单系统中的实践三DDD分层协作实践

DDD 分层合作

领取订单分层

用户接口层：适配不同终端（gateway api、dubbo api、kafka consumer）生成 Command

|-com.yit.orders.facade:
    |-com.yit.orders.facade.OrderPayService：创立 OrderPayCommand，交由 PayingOrderCommandHandler 执行 

应用服务层：执行来自用户界面层的命令，不实现具体业务。个别过程为，通过畛域仓储拜访聚合，调度聚合的行为函数响应命令，治理聚合对应的事务并通过畛域仓储对聚合进行长久化，通过事件总线公布和订阅聚合产生的畛域事件；

|-com.yit.orders.module.paying.application
    |-command
        |-com.yit.orders.module.paying.application.command.OrderPayCommand：领取指令
        |-com.yit.orders.module.paying.application.command.PayingOrderCommandHandler：领取指令的执行（应用服务，治理多个聚合的事务，领取订单的例子中仅操作一个聚合）|-domainEventHandler
        |-com.yit.orders.module.paying.application.domainEventHandler.pay.common.OrderPayEventHandler：订阅畛域事件（通过订阅模型进行解耦）

畛域层：次要实现畛域模型的外围业务逻辑，体现畛域模型的业务能力。聚合确保业务逻辑的原子性和一致性（聚合内实体的事务边界），产生畛域事件。

|-com.yit.orders.module.paying.domain
    |-aggregate
        |-com.yit.orders.module.paying.domain.aggregate.IPayingOrderRepository：定义聚合仓储接口（依赖倒置）|-com.yit.orders.module.paying.domain.aggregate.ReadWritePayingNormalOrder：聚合（写模型），内聚业务逻辑，所有的业务扭转都必须通过聚合达成
    |-event
        |-com.yit.orders.module.paying.domain.event.pay.common.OrderPayEvent：畛域事件（值对象，由聚合或实体产生，在应用层进行公布，进行聚合边界之外的通信）|-readonly
        |-com.yit.orders.module.paying.domain.readonly.ReadonlyPayingOrder：读模型 

畛域仓储层：

|-com.yit.orders.module.paying.infrastructure
    |-com.yit.orders.module.paying.infrastructure.PayingOrderRepository：实现了畛域层定义畛域仓储接口（通过接口的形式达到外层依赖内层）

实现参考：

举荐一下 MS 的这个官网微服务示例我的项目

EShopOnContainers

设计面向 DDD 的微服务

DDD 分层