服务的封装与组合
- 微服务的服务是从领域层逐级向上封装、组合和暴露
基础层
服务形态主要是仓储服务。仓储服务包括接口和实现：
- 仓储接口服务供应用层或领域层服务调用
- 仓储实现服务，完成领域对象的持久化或数据初始化
领域层
领域层实现核心业务逻辑，负责表达领域模型业务概念、业务状态和业务规则。主要的服务形态有实体方法和领域服务。
实体采用充血模型，在实体类内部实现实体相关的所有业务逻辑，实现的形式是实体类中的方法。
实体是微服务的原子业务逻辑单元。在设计时我们主要考虑实体自身的属性和业务行为，实现领域模型的核心基础能力。不必过多考虑外部操作和业务流程，这样才能保证领域模型的稳定性。
业务规则和逻辑校验在领域层。
DDD提倡富领域模型，尽量将业务逻辑归属到实体对象，实在无法归属的部分则设计成领域服务。领域服务会对多个实体或实体方法进行组装和编排，实现跨多个实体的复杂核心业务逻辑。
对于严格分层架构，如果单个实体的方法需要对应用层暴露，则需要通过领域服务封装后才能暴露给应用服务。
应用层
表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，负责不同聚合之间的服务和数据协调，负责微服务之间的事件发布和订阅。
通过应用服务对外暴露微服务的内部功能，这样就可以隐藏领域层核心业务逻辑的复杂性以及内部实现机制。
应用层的主要服务形态有：
- 应用服务
- 事件发布
- 订阅服务
应用服务内用于组合和编排的服务，主要来源于领域服务，也可以是外部微服务的应用服务。
应用服务内还可完成
- 安全认证
- 权限校验
- 初步的数据校验
- 分布式事务控制
为了实现微服务内聚合之间的解耦，聚合之间的服务调用和数据交互应通过应用服务来完成。原则上我们应该禁止聚合之间的领域服务直接调用和聚合之间的数据表关联。
用户接口层
前端应用和微服务之间服务访问和数据交换的桥梁。
处理前端发送的Restful请求和解析用户输入的配置文件等，将数据传递给应用层
或获取应用服务的数据后，进行数据组装，向前端提供数据服务。
主要服务形态是Facade服务。
Facade服务分为接口和实现两个部分。完成服务定向，DO与DTO数据的转换和组装，实现前端与应用层数据的转换和交换。
两种分层架构的服务依赖关系
松散分层架构
- 领域层的实体方法和领域服务可直接暴露给应用层和用户接口层，而无需逐级封装。
缺陷
- 易泄露领域层核心业务逻辑
- 当实体方法或领域服务发生变更，由于服务同时被多层服务调用和组合，难以找出哪些上层服务调用和组合了它，不方便通知到所有的服务调用方
- 该分层架构中，实体A的方法在应用层组合后，暴露给用户接口层aFacade。abDomainService领域服务直接越过应用层，暴露给用户接口层abFacade服务。松散分层架构中任意下层服务都可以暴露给上层服务。
严格分层架构
每层服务只能向直接上层提供服务。虽然实体、实体方法和领域服务都在领域层，但实体和实体方法只能暴露给领域服务，领域服务只能暴露给应用服务。
服务如果需要跨层调用，下层服务需要在上层封装后，才可以提供跨层服务。
比如实体方法需向应用服务提供服务时，需先封装成领域服务。
通过封装：
- 可避免泄露核心业务逻辑的实现
- 避免在应用层沉淀过多本属领域层的核心业务逻辑，防止应用层臃肿
- 当服务发生变更时，由于服务只被紧邻上层的服务调用和组合，只需逐级告知直接上层
- A实体的方法需封装成领域服务aDomainService才能暴露给应用服务aAppService。abDomainService领域服务组合和封装A和B实体的方法后，暴露给应用服务abAppService
