DDD领域驱动设计内容分享(十二)：爱奇艺打赏服务，如何DDD架构？

之乎者也·

已于 2024-02-02 23:43:35 修改

阅读量921

点赞数 14

分类专栏： DDD领域驱动设计内容分享架构设计内容分享文章标签：架构 java DDD

于 2023-12-28 09:46:28 首次发布

本文链接：https://blog.csdn.net/qq_45038038/article/details/135162398

版权

架构设计内容分享同时被 2 个专栏收录

224 篇文章 49 订阅

订阅专栏

DDD领域驱动设计内容分享

46 篇文章 17 订阅

订阅专栏

爱奇艺打赏业务DDD实践

作者：爱奇艺会员技术团队

领域驱动设计(Domain-Driven Design，以下简称DDD)思潮的形成要追述到30几年前，17年前，Eirc Evans定义了领域驱动设计的概念。

DDD为传统行业的软件工程师提供了一种新的设计方法论，但在互联网领域的应用却相对较少。

然而，随着互联网行业对业务复杂性的应对以及对微服务架构的偏好，DDD再次回到了人们的视线之中。本文将主要探讨如何应对软件复杂性问题。

互联网的行业的业务越来越复杂，面临与传统行业软件相同的问题；
微服务的流行带火了DDD，以解决微服务拆分问题。

本文主要对第一点“解决软件复杂性之道”进行讲解。

价值

详细讲解之前，我们先给出DDD为打赏业务带来的价值。

会员业务部门在打赏业务中实践 DDD 后，取得了以下显著成果：

新需求接入开发成本节约20%；
更换底层中间件开发成本节约20%；
项目熟悉成本节约30% (对DDD有基本了解为前提)；
单测开发成本指数级降低；
上线风险、成本降低。

了解了DDD流行的背景及业务价值后，下面我们对DDD是什么、有哪些优势、项目中如何实践，以及几个关键问题进行叙述。

领域驱动设计是什么

讨论领域驱动设计是什么之前，我们先看下面一段代码：

这是一个打赏接口定义，单看这个接口是没有问题的，用户基于活动，选择明星，选择道具进行打赏。

业务逻辑上没问题，但我们会发现一些代码的坏味道。

代码编译后方法的参数名会丢失。

在编码过程中，如果明星和道具的参数顺序传递错误，代码仍可顺利编译，但只有在运行时才会暴露出业务错误。尽管这种问题的发现成本相对较低，但在编译阶段就能发现并避免这类错误，可以降低问题的排查成本。在上述方法中，参数编码可以唯一标识实体，但失去了实体在业务领域的实际意义，例如为特定明星赠送特定道具。

在打赏业务逻辑中，存在大量与核心业务无关的前置校验逻辑，这会影响代码的可读性。所有逻辑都堆叠在一个方法中，增加了编写测试用例的复杂度。

这些问题出现的根本原因在于对业务领域的划分不够明确，仅仅实现了操作流程，缺乏领域抽象。方法参数定义缺少业务领域含义。实际上，活动校验本质上是活动属性判断，活动是否有效取决于活动自身的属性。可以将活动校验抽象为 ActivityValidate 类，或在实体中增加 validate 方法。更进一步，可以将校验逻辑直接放在活动的构造方法中，既能达到校验目的，又避免漏校验。这样，在编写单元测试时，将大逻辑拆分为多个逻辑单元，可以大大减少用例数量。优化后的代码如下：

针对活动校验，我们可以采用构造函数校验，因此在打赏方法中无需再进行校验。将活动校验放在前置构造函数中，有助于降低测试用例数量。

回到最初的问题，什么是领域驱动设计？

1、领域驱动设计基于领域建模而非数据建模

在上面的例子中，重构前 activity 实体仅具有基本属性和 get/set 方法，即“失血模型”。这导致 activity 作为领域对象退化为数据对象，仅用于 ORM 组件的 CRUD 操作。失血模型在项目代码中随处可见。其原因与对象-关系映射（ORM，如 Hibernate）持久化机制的流行直接相关。使用 ORM 将每个类映射到一张数据表，通过实体对象完成 CRUD 操作，久而久之，实体成为 ORM 框架的专用名词，失去了领域能力。在进行项目设计时，应从业务领域角度出发，而非数据库角度。我们将在战略设计部分详细讨论这一问题。

2、满足六边形架构设计

六边形架构将在后续章节中详细介绍，洋葱架构、干净架构与六边形架构相似。

满足以上两点，并对 DDD 的一些概念进行映射实践，那么你的系统已符合 DDD。总结来说，DDD 并非一套全新的特殊架构，而是项目代码经过重构，满足高可维护性、高可扩展性、高可测试性、代码结构清晰之后必然达到的终点。

领域驱动设计（DDD）是一种软件设计方法，它强调基于领域建模而非数据建模，关注六边形架构设计。通过实践 DDD，我们可以更好地应对业务复杂性，实现软件系统的卓越表现。在实际项目中，根据业务需求和场景，灵活运用 DDD 理念和相关架构，构建高质量、高可维护和易于扩展的软件系统。

DDD打赏业务实践

1、打赏业务简介

观看视频时，选择明星、礼物进行打赏；
打赏后屏幕有气泡提示；
打赏数据在排行榜进行显示；
累计一定的打赏获得某种奖励。

2、战略设计

在谈论战略设计时，我们必须了解几个核心概念：领域、子域、限界上下文和架构分层。

领域：广义上讲，领域代表了组织所从事的业务范围及其涉及的所有内容。每个公司或组织都有其独特的业务领域和运营方式，这个领域即为该公司或组织的业务范围及在其中进行的活动。当你为某个企业开发软件时，你所面对的就是这个企业的领域。对于你来说，这个领域应该是清晰明确的，因为你是在这个领域内开展工作。

对于打赏这种业务，打赏本身便是领域，即打赏领域。无论你的打赏对象是一位主播、一部电影或者一篇博文，又无论你的打赏道具是RMB、虚拟币、火箭等等，打赏都是这个领域的核心。

子域：领域模型可能会让我们认为整个业务系统应该构建一个单一、紧凑、功能齐全的模型。然而，这并不是 DDD 的目标。相反，在 DDD 中，一个领域被划分为多个子领域。这些子领域有助于我们更加关注业务系统的某一特定方面，从而实现领域的有效拆分。

限界上下文：限界上下文是一个具有明确边界的特定职责范围。在这个范围内，领域模型中的每个概念（包括属性和操作）都有其特定的含义。

打赏系统搭建之初，需求比较简单，随着业务的发展，需求不断复杂化，领域拆分及迭代如下：

初期，运营和产品需求简单，只需实现免费打赏功能并在界面展示打赏气泡，因此将整个系统划分为一个领域；
经过一段时间的试水，发现活动效果不错，需求方希望增加支持多场打赏活动。为了实现这个目标，我们需要新增活动支撑子领域；
随着需求的进一步升级，用户在达到一定打赏额度后可以获得奖品。为了实现这个功能，我们引入了奖励子领域；
为了提高用户的参与度，我们增设了排行榜功能，从而引入了排行榜子领域。

最终领域划分如下图：

打赏核心子域：完成打赏操作。
通知子域：实现界面气泡通知能力。
奖励子域：奖励策略匹配，奖励发放。
排行子域：完成排行功能。
活动子域：活动、明星、道具管理。
用户子域：完成用户查询、校验等通用能力。

领域的拆分过程并没有上面描述的那么顺利，经历了很多推翻重来的过程，正是经历了这些过程，我们对领域的理解才能更深入，更符合领域建模。

架构分层：分层架构的一个关键原则是，每层只能与下方层发生聚合。

为了解耦接口定义与实现，我们将接口定义在领域层，实现定义在基础设施层。但这样违反了从顶至底的单项依赖原则。

为了解决这个问题，我们采用依赖倒置原则——高层模块不应该依赖于低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

根据此原则，结构调整如下：

我们将基础设施层置于所有层次结构的顶部，使其能够实现其他层次定义的接口。

在分层架构中遵循依赖倒置原则，可能会发现分层概念实际上已不再存在。无论是高层次还是低层次，它们都仅依赖于抽象。

这样一来，整个分层结构仿佛被推平，客户可以以“平等”的方式与系统交互。当加入新的客户时，它们仅作为不同的输入、输出以及展示形式，这就是我们将要了解的另一种架构——六边形架构。

六边形架构

在我们的代码库中，有许多直接的外部依赖和实现细节，例如 MyBatis 的 Mapper 类、HttpClient 注入、RocketMQ 的监听、缓存的直接操作等。

这种实现方式有两个明显的问题：

一是当底层更换基础组件时，会对业务逻辑产生直接影响，导致代码修改量和测试范围大幅增加；
二是缺乏功能复用性，若其他业务有类似逻辑，无法直接移植和复用。

于 2005 年，Alistair Cockburn 提出了六边形架构，亦称为端口和适配器架构。

从上图可以看出，针对核心的应用程序和领域模型，其他底层依赖或实现都可以抽象为输入和输出两类。

组织关系变成了一个二维的内外关系，而非上下结构。每个 I/O 与应用程序之间都有适配器进行隔离，每个最外围的边都代表一个端口。

基于六边形架构设计的系统是领域驱动设计（DDD）所追求的最终形态。六边形架构的实践将在“DDD 优势”部分进行详细阐述。

先给出基于六边形架构实践后，项目模块结构：

模块	说明
Admin-api	配置后台相关
api	对外用户接口
application	应用
domain	领域
infrastructure	基础设施
query	查询模块
task	与使用的中间件相关，可忽略
worker	处理事件消息模块
common	基础包

通过六边形架构，我们可以更有效地实现领域模型的内外分离，降低外部依赖，提高代码的可维护性和复用性。在实际项目中，我们可以根据业务需求和场景，灵活运用六边形架构，将底层实现与领域模型分离，使代码更具灵活性和可扩展性。六边形架构有助于我们实现高质量、高可用的软件系统，满足不断变化的业务需求。

3、战术设计

在战略设计的基础上，领域边界已清晰可见。接下来，我们讨论战术设计，首先对领域驱动设计（DDD）的几个基本概念进行业务映射。

实体：由属性和行为组成，具有唯一标识。

在设计系统时，我们往往侧重于数据而非领域。对于 DDD 开发者来说，这种情况同样存在，因为在软件开发中，数据库仍然占据主导地位。首先考虑的是数据的属性和关联关系，而非具有丰富行为的领域概念。

这种做法的结果是将数据模型直接映射到对象模型上，导致实体仅包含 get/set 方法，这并非 DDD 的风格。

只有get/set实体需配合service使用，内聚性、可维护性，以及复用迁移成本均明显高于DDD的做法。

值对象：没有唯一标识，具有可度量或可描述，并满足不变性的对象。

我们应该尽量使用值对象来建模而不是实体对象，因为相比实体，我们可以非常容易地对值对象进行创建、测试、使用、优化和维护。

对于第一种实现，用户必须了解同时使用 amount 和 currency，并清楚如何运用这两个属性。这是因为这两个属性并未构成一个概念整体。对于 PropName 值对象的定义，可以带来一定的扩展性。例如，如果需要对道具名称进行大小写转换，可以在 PropName 内部实现此操作，而无需将相关逻辑泄漏到 Prop 中。

领域服务：

领域服务表示一个无状态的操作，用于实现特定于某个领域的任务。

当某个操作不适合放在聚合和值对象上时，最好的方式便是使用领域服务了。

例如“用户认证”，一种方式是我们可以简单地将认证操作放在实体上。

对于这种设计，存在两个问题。

首先，用户类需要知道某些认证细节，
其次，这种方法也不能显示的表达通用语言。

这里我们询问的是一个User“是否被认证了”，而没有表达出“认证”这个过程。

在有可能的情况下，我们应该尽量使用建模术语直接地表达出交流语言。

领域事件：领域专家所关心的发生在领域中的一些事件。我们通常将领域事件用于维护事件的一致性，这样可以消除两阶段提交(全局事务)。

聚合：聚合是一组相关对象的组合，作为一个整体被外界访问，聚合根是这个聚合的根节点。

聚合是核心领域的重要概念，它可以用来说明领域内的关系。

此外，聚合在技术上也有很高的价值，可以指导详细设计。聚合由根实体、实体、值对象组成。

工厂：工厂提供一个创建对象的接口，封装了所有创建对象的复杂操作过程。

同时，客户无需直接引用实际被创建的对象。

在实际应用中，我们可以根据业务需求和场景，灵活运用工厂模式。工厂模式可以简化对象创建的过程，提高代码的可维护性和可扩展性。通过封装创建对象的复杂操作，工厂模式还可以降低代码之间的耦合度，便于后续的优化和扩展。在项目中，我们可以根据实际需求，定义不同的工厂类来创建相应的对象，从而实现对象的灵活创建和管理。