GuilinDev

Dubbo Review

08 August 2020

领域驱动

DDD 是软件行业的一种成熟的方法论和模式。通过应用 DDD，我们能够很好的将需求应对到设计，能够让开发聚焦业务本身而不是技术，能够让代码体现我们设计，能够让团队在一个框架内有节奏的开发。

DDD 核心概念

DDD 是一种开发理念，核心是维护一个反应领域概念的模型（领域模型是软件最核心的部分，反应了软件的业务本质），然后通过大量模式来指导模型设计与开发。

具体方法是首先需要将需求分析后，形成一个反应需求的领域模型。领域模型就是大家平常理解的类、类的属性、类之间的关系等。当然在 DDD 中，为了更好的将领域模型反应需求， 对类、类的属性、类之间的关系等有一些模式的指导。比如类的属性可能是一般属性，也可能是值对象；比如有关系的类之间是否是代表一个整体概念、有相同生命周期、需要统一持久化等。 所以我们的领域模型除了能够跑通需求外，还要考虑聚合根、实体、值对象、聚合等概念的应用，这样领域模型的设计才能更好的反应需求，也能够更好的将设计对应成有约束力的代码。

另外 DDD 也提供了大量模式，告诉我们应该如何编写对应设计的代码，能够将我们的代码真正映射到设计；如何进行业务逻辑与持久化机制的剥离；如何进行更好的架构设计等。

DDD应对复杂性

在软件设计与开发过程中，复杂性主要体现在三个方面。 一是技术维度，有业务代码的实现、有与数据库或其他持久化存储交互的实现、有消息队列的实现、有身份验证与授权的实现、有 WebAPI 暴露的实现等； 二是业务维度，有太多的模块和功能需要去做； 三是时间维度，需要快速的开发，快速的响应需求的变更，快速的修正 Bug等。

针对上面的三个维度，DDD的应对如下：

  1. 技术维度：通过合理的架构分层，能够让每层关注自己的事情，比如领域层只关注业务逻辑的事情，仓储实现层只关注持久化数据与查询的事情， 应用服务层只关注协调领域层与仓储实现层完成用例的事情，接口层只关注暴露给前端的事情。

  2. 业务维度：通过将大系统划分成多个界限上下文，可以让不同团队和不同人只关注当前上下文的开发。 在当前界限上下文中的领域层、仓储实现层、应用服务层、接口层都与其他界限上下文独立开来，这样可以专注开发，并且在修改代码与发布产品时，影响面较小。

  3. 时间维度：通过敏捷式迭代快速验证，快速修正。

如何学习DDD

要学习一种方法论和架构模式，两个步骤：一是了解它核心的概念和组件，二是将这些概念和组件灵活的运用到产品开发中。

要高效的学习 DDD，首先我们要搞清楚两个方面的内容：一是核心的组件和概念，二是 DDD 分层架构

核心组件和概念

  1. 界限上下文：首先要将大系统划分为多个界限上下文，比如一个经销商电商系统可以划分为产品、经销商、订单等几个界限上下文，每个界限上下文有自己的领域逻辑、数据持久化、用例、接口等。 每个界限上下文根据特点，具体实现方式又不同，比如有些界限上下文基本没有业务逻辑，就是增删改查，则可以使用 CRUD 最简单的模式；有些界限上线文有一定的业务逻辑， 但对高并发、高性能没要求，则可以使用经典 DDD 模式；有些界限上下文有一定的业务逻辑，而且有高性能要求，则可以使 CQRS 模式。 划分界限上下文并且在每个上下文实现自己的业务逻辑、 持久化、用例和接口作用是巨大大，一是可以让不同开发小组专注与此界限上下文的开发，二是可以分别部署，三是如果一个界限上下文出现问题，并不影响其他界限上下文功能的使用。

  2. 实体：有业务生命周期的对象，采用业务标识符进行跟踪。比如一个订单就是实体，订单有生命周期的，而且有一个订单号唯一的标识它自己，如果两个订单所有属性值全部相同， 但订单号不同，也是不同的实体。

  3. 值对象：无业务生命周期，无业务标识符，通常用于描述实体。比如订单的收货地址、订单支付的金额等就是值对象。值对象在数据库中表的表现形式可以是两种， 一种是作为一个列或多个列与所属的实体对象所对应的表放在一起，另一种是单独一个表，通过ID与所属的实体对象关联。

  4. 领域服务：无状态，有行为，通常就是一个用例来协调多个领域逻辑完成功能。

  5. 聚合：通常将多个实体和值对象组合到一个聚合中来表达一个完整的概念，比如订单实体、订单明细实体、订单金额值对象就代表一个完整的订单概念，而且生命周期是相同的， 并且需要统一持久化到数据库中。

  6. 聚合根：将聚合中表达总概念的实体做成聚合根，比如订单实体就是聚合根，对聚合中所有实体的状态变更必须经过聚合根，因为聚合根协调了整个聚合的逻辑，保证一致性。 当然其他实体可以被外部直接临时查询调用。

  7. 服务：协调聚合之间的业务逻辑，并且完成用例。

  8. 仓储：用于对聚合进行持久化，通常为每个聚合根配备一个仓储即可。仓储能够很好的解耦领域逻辑与数据库。

经典分层架构

传统三层架构的问题包括：

  • 过分注重数据访问层，而不重视领域。
  • 业务逻辑直接与数据访问层耦合，与领域为核心的 DDD 思想背道而驰。
  • 没有一系列的模式与方法论指导这种分层架构的开发约束。

  1. 基础结构层：整个产品或系统的底层支撑。
  • 常用工具、支撑功能：这个 .net core 项目至少要实现以下的功能：Json 配置文件的读取、WebAPI 返回给前端的基本格式对象的定义、Json 序列化与反序列化、加密功能、依赖注入框架的二次封装等。
  • 支持 DDD 框架：这个 .net core 项目至少要实现以下的功能：聚合根接口定义、实体接口定义、值对象接口定义、仓储接口定义、仓储接口的 EF Core 顶层实现（工作单元模式）。
  • 聚合根仓储实现：这个 .net core 项目严格来讲其实不属于基础结构层部分，只是由于习惯，把它放到基础结构层这个解决方案文件夹中。它其实是引用了领域层的领域对象，并且从领域层对应的聚合根仓储接口中继承，然后实现领域对象持久化到数据库，这样，仓储实现是依赖领域对象，领域对象与领域逻辑就不需要依赖仓储。领域模型才是系统真正的核心。
  1. 领域层：界限上下文的领域逻辑
  • 首先要实现这个界限上下文的领域对象的 POCO 模型。
  • 然后针对这个界限上下文的所有领域对象，建立每个领域对象自己的业务逻辑，注意的是，领域对象的业务逻辑最好不与仓储直接发生交互，就算领域逻辑要临时查询数据库也不要这样。
  • 定义该界限上下文聚合根的仓储接口，这个接口代表的是聚合根与持久化打交道的基础约束，具体实现还是在基础结构层的聚合根仓储中实现，这样就实现了解耦。把聚合根仓储接口定义在领域层的意义是可以为领域层的调用方（应用服务层）的用例提供对聚合持久化支持。
  • 定义该界限上下文的 EF Core 上下文接口并实现，这样就通过映射关系，EF Core 就可以处理领域对象与数据库表之间的映射了。
  1. 应用服务层：界限上下文的用例
  • 某个上下文的应用服务层的某个用例，通过调用领域对象的领域逻辑，完成相关领域逻辑的实现。
  • 领域逻辑完成后，应用服务层用例调用领域层的聚合根的仓储接口的方法，完成领域对象的预持久化。（应用服务通过基础结构层的依赖注入框架与 Json 配置文件找到聚合根仓储接口对应的实现）
  • 应用服务层用例然后调用基础结构层的 EF Core 仓储接口的工作单元方式，完成真正的持久化。（应用服务通过基础接口层的依赖注入框架与 Json 配置文件找到顶层仓储接口对应的工作单元实现）
  • 用例返回给接口层需要的前端所需的 Json 对象格式。
  1. 接口层：非常薄的一层
  • 只需要调用应用服务层用例
  • 向前端返回所需的json对象格式

DDD落地

####

###

组件设计原则

中台架构

This site is open source. Improve this page.