当今微服务盛行之架构师必经之路-领域驱动设计-下

DDD架构

传统分层架构

分层架构设计就是为了帮助我们达到高内聚、低耦合复用性设计和扩展性设计。整洁架构、CQRS、六边形架构等微服务架构都旨在实现“高内聚低耦合”，而分层架构基本原则是每层只能与位于其下方的层发生耦合。分层架构又分为两种：

• 严格分层架构(Strict Layers Architecture)，某层只能与其直接下层耦合。
• 松散分层架构(Relaxed Layers Architecture)，允许任意上层与任意下层耦合。由于用户接口层和应用服务通常需要与基础设施打交道，许多系统都是该架构。

DDD分层架构

DDD分层架构包含用户接口层、应用层、领域层和基础层；通过这些层次划分，我们可以明确微服务各层的职能，划定各领域对象的边界，确定各领域对象的协作方式。DDD的分层架构中基础层与用户接口层、应用层和领域层都可能有关系，提供基础能力给其他三层调用。

• 用户接口层：显示信息给用户，如对外的model、模型的转换。一般包括用户接口、Web 服务等，只处理用户显示和用户请求，不应包含领域或业务逻辑。用户接口层很重要，在于前后端调用的适配，Facade接口就起很好的作用，包括DO和DTO对象的组装和转换等。
• 应用层：主要包含线程调度，应用服务，与模型进行与实体无关的业务逻辑。理论上不应有业务规则或逻辑，而主要是面向用例和流程相关的操作。
  • 应用层位于领域层之上，因为领域层包含多个聚合，所以它可协调 多个聚合服务和领域对象完成服务编排和组合 ，协作完成业务。
  • 应用层也是微服务间的交互通道，它可调用其它微服务，完成 微服务间的服务组合和编排 。
  • 开发设计时，不要将本该放在领域层的业务逻辑放到应用层。因为庞大的应用层会使领域模型失焦，时间一长微服务就会演化为传统MVC三层架构，导致业务逻辑混乱。
  • 应用服务是在应用层，负责服务的组合、编排、转发、转换和传递，处理业务用例的执行顺序以及结果的拼装，以粗粒度服务通过API网关发布到前端。还可进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
• 领域层：业务概念、规则、领域模型。主要包含聚合、聚合根、实体、值对象、领域服务等领域模型中的领域对象。
  • 聚合根：如果把聚合比作组织，聚合根则是组织的负责人，聚合根也叫做根实体，它不仅仅是实体，还是实体的管理者。
  • 聚合：高内聚低耦合，是领域模型中最底层的边界，可以作为拆分微服务的最小单位，但是不建议单独对应一个微服务，除非是对性能有极致要求的场景，一个微服务可以包含多个聚合，聚合之间的边界是逻辑最天然的边界，有了这个逻辑边界，就可以在微服务拆分的时候作为拆分和组合依据，微服务架构演进也就不是难事了。
  • 聚合根的特点：聚合根是实体，具备唯一标识，有