DDD应用层代码结构

application(应用层）：
    应用层主要是向上为接口层提供统一的应用服务，向下对领域层进行领域层的领域服务进行重组、编排和组合的功能。应用服务层也可以直接访问基
    础设施层的接口来进行应用编排，但是不能在应用层做领域相关的业务逻辑处理，只能做针对前端应用的业务逻辑处理，避免领域层的领域业务退化
    将DDD退化为传统的MVC三层架构。应用层主要目录结构包括（event和service)。
    event(事件）:主要存放事件相关代码，其中包括(publish 和 subscribe）两个目录
                publish：主要存放事件发布相关代码
                subscribe:主要存放事件订阅相关代码
                注意：事件发布与定义在领域层也同样可以存放，那样在发生领域事件时，会出现领域层调用领域层服务的现象，如果事件较多
                会使得调用混乱，所以不建议将事件发布与订阅放到领域层，发布订阅放到应用服务层，由应用层来做统一的领域事件编排，保持领
                域层的业务逻辑清晰。
    service(应用服务)：应用服务会对多个领域服务或其他微服务(领域)进行封装、编排和组合，对外提供粗粒度的服务，可以针对每一个聚合
                的应用设计一个应用服务类。如:电商中的交易环节，其中包括下单，支付等环节，而下单，支付可能由不同的微服务提供相关的服务，
                我们可以把相关的流程通过应用服务对各个微服务进行编排，组合后形成一个组合，对前端提供统一的交易服务。
                对于多表关联的复杂查询，由于这种复杂查询不需要领域逻辑和业务规则约束，因此不建议将这类复杂的查询放在领域层的领域模型中。
     注意：在进行跨微服务(领域)调用时，部分DO对象需要转换为DTO对象，所以应用层可能也会有用户接口层的assember和dto对象。这是你可以根据
          需要增加assember和dto代码目录