《DDD第一篇》- DDD基础入门

目录

1、什么是DDD

2、DDD中的重要概念

领域

实体、值对象、聚合

Bounded Context - BC

3、DDD的几种架构模式

分层架构

CQRS架构-读写分离架构

事件驱动架构

架构异同及关系​​​​​​​

---

1、什么是DDD

DDD（Domain-Driven Design）领域驱动设计，是一种软件设计方法论，旨在帮助开发者更好地理解和设计复杂业务领域的软件系统

DDD的核心是将软件系统的设计重心放在业务领域（domain）本身，而非技术实现上。在DDD中，业务领域被视为软件系统的核心，包括业务概念、业务流程、业务规则等，而其它方面如技术实现、数据存储等则被视为次要的。

DDD强调开发者需要深入了解业务领域，与领域专家紧密合作，通过对业务领域的抽象和建模，将复杂的业务问题分解为更小的领域问题，并将这些问题映射到软件系统中的对象和模块。同时，DDD还提供了一些实践方法和模式，如聚合、实体、值对象、领域服务、事件驱动等，帮助开发者更好地实现复杂业务逻辑，提高软件系统的可维护性和可扩展性。

2、DDD中的重要概念

领域

• 领域，即问题域、问题空间，领域是一种边界、范围。所以，一个领域代表了一个问题域的边界，也可以理解为是一个业务的边界。领域边界越大，业务范围就越大，反之则相反。通常我们大家交流都比较喜欢用业务这一词，比如这块业务，那块业务，这就是不同的业务不同的边界。领域一词，相对比较抽象。

• 领域既然是一个边界，所以可以划分领域的大小，即领域划分，划分出来的子领域简称子域，每个子域对应一个小的问题域和小的业务；当然，不同的子域的重要性也是不同的，所以又进行了分类如核心子域、支撑子域、通用子域。

核心子域：包含企业核心业务和竞争力的子域可以划为核心域，他们是企业业务能够成功运行的关键所在

通用子域：具有通用功能的子域可以划为通用域。通用域可以同时被多个子域调用，例如鉴权、操作日志等。

支撑子域：除核心域和通用域之外的子域可以算是支撑域，例如数据字典、消息通知等

一个业务领域往往由多重不同类型的子域为其提供服务

    领域的拆分不是一步到位的，因为你无法准确预知以后的业务发展方向，应该根据实际情况划分出领域的细度，比如一开始先按粗粒度的划分，根据需求迭代在从某个粗粒度划分出多个细粒度，比如商品中心，一开始划分商品服务，随着商品业务越来越复杂，可能需要划分出类目服务、库存服务、价格服务等。当然如果已经是某个领域的专家，那你可提前进行较细粒度的划分。

实体、值对象、聚合

•     值对象是没有唯一标识符的对象，它的状态通过其属性值来定义，通常被用作实体的属性。值对象可以在实体和聚合根中使用，但是它们不能单独存在。值对象不可改变，但可被替换。

        哪些是值对象：例如订单场景中的收获地址、交易快照。

• 实体是具有唯一标识符的对象，它的状态通过其属性值和生命周期来定义。实体通常是业务领域中最重要的概念之一，可以与其他实体、值对象和聚合根建立关联关系。

           哪些是实体：商品、用户等大部分业务对象都可以是实体。用户收货地址也可以是实体，比如在用户收获地址管理模块中。

•    聚合根是一组相关对象的集合，由一个具有唯一标识符的实体来代表。聚合根可以包含值对象、实体和其他聚合根，它们一起构成了聚合。

          哪些是聚合根：在电商交易场景中，订单是聚合根，订单项，收货地址、用户信息共同聚合成了订单。

订单场景中聚合根、值对象、实体三者关系

 值对象描述了一个值的概念，而实体描述了一个具有唯一标识符的业务对象，聚合根是一组相关的实体和值对象的集合，由一个具有唯一标识符的实体来代表。它们之间的区别在于是否具有唯一标识符、是否可以单独存在以及是否可以与其他对象建立关联关系

Bounded Context - BC

• BC定义

      Bounded Context，中文翻译为限界上下文，BC的理解分为两个层面：

  • Bounded，表示边界的意思；

  • Context，即上下文，我理解为是一个场景的上下文，这个场景不局限于普通的业务场景，而是各种上下文都涵盖在内，是一个时空感知的概念。比如我们两个人在公司交谈时的上下文是一个上下文，但是在路上交谈时，则切换到另一个上下文了，因为交谈的地点发生了变化，所以，BC合起来理解，就是一个上下文的边界。

• BC作用

  • BC就是为了表达上面介绍的某个粒度解决方案的上下文边界。那为何要强调这个边界呢？有了这个边界，我们才可以定义这个边界内的领域模型中所有对象概念的明确含义。如果没有这个上下文边界，对同一概念在不同上下文的理解，大家就会产生偏差。

  • 举个栗子，商品：
  •  在商品中心的BC中，商品中心负责管理电商平台的所有商品，所以商品在商品中心BC中，是一个聚合根，但是在订单BC中，虽然也叫商品，但是它只是一个值对象，订单中心的订单是一个聚合，订单内聚合了多条订单明细，每个明细是一个实体，每个订单明细对应了一个商品，但这个商品本质上只是商品中心的商品的一部分信息，如商品ID、标题、价格，且是只读的。甚至更为常见的，叫同一个名称的对象，在不同的BC中是属性完全不一样的不同对象。

3、DDD的几种架构模式

分层架构

由表示层、应用层、领域层和基础设施层组成。这种架构将应用程序划分为不同的层次，每个层次有着不同的职责，从而提高代码的可维护性和可测试性。

分层架构中一个重要原则是每层只能与位于其下方的层发生耦合。分层架构又可以简单分为两种，即严格分层架构和松散分层架构。在严格分层架构中，某层只能与位于其直接下方的层发生耦合，而在松散分层架构中，则允许某层与它的任意下方层发生耦合。

代表架构

四层架构、洋葱架构、六边形架构、整洁架构

CQRS架构-读写分离架构

  CQRS架构是一种用于构建分离读操作和写操作的应用程序架构。它通过将应用程序分成命令端和查询端两个部分来实现这种分离。命令端负责处理对应用程序的写操作，而查询端负责处理对应用程序的读操作。

应用场景：

   大流量高并发场景数据库的读写分离、电商系统中订单写操作与订单查询操作分离为两个Service等

事件驱动架构

基于事件和消息传递的架构，强调解耦和异步处理。在这种架构中，系统中的各个部分通过事件和消息进行通信，事件通常由某个状态的改变触发，消息则由发送者直接发送。事件和消息的处理通常是异步进行的，从而提高了系统的吞吐量和可扩展性。

应用场景

电商创建订单场景，可以发送订单创建事件，各个业务通过接收事件完成例如优惠券预占、积分赠送、库存扣减等业务逻辑处理

架构异同及关系

   分层架构强调将领域模型作为设计的核心，CQRS架构则强调命令和查询的分离，而事件驱动架构则更加关注系统中各个部分之间的解耦和异步处理。

    通过以上分类及实践过程我们发现，在实际复杂的业务场景中，整个系统往往采用分层架构来做为主要设计，并与其它两种模式组合使用。

更多知识请查看下一篇，下一篇将介绍四层架构、洋葱架构及在交易中的应用

《DDD第二篇》- DDD在交易系统中的应用