DDD落地：爱奇艺打赏服务，如何DDD架构？

尼恩说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格，遇到很多很重要的面试题：

谈谈你的DDD落地经验？

谈谈你对DDD的理解？

如何保证RPC代码不会腐烂，升级能力强?

微服务如何拆分？

微服务爆炸，如何解决？

你们的项目，DDD是怎么落地实操的？

所以，这里尼恩给大家做一下系统化、体系化的梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

也一并把这个题目以及参考答案，收入咱们的 《尼恩Java面试宝典PDF》V144版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】取

除了本文，尼恩输出了一个 《从0到1，带大家精通DDD》系列，帮助大家彻底掌握DDD，链接地址是：

《阿里DDD大佬：从0到1，带大家精通DDD》

《阿里大佬：DDD 落地两大步骤，以及Repository核心模式》

《阿里大佬：DDD 领域层，该如何设计？》

《极兔面试：微服务爆炸，如何解决？Uber 是怎么解决2200个微服务爆炸的？》

《阿里大佬：DDD中Interface层、Application层的设计规范》

《字节面试：请说一下DDD的流程，用电商系统为场景》

《DDD如何落地：去哪儿的DDD架构实操之路》

《DDD落地：从腾讯视频DDD重构之路，看DDD极大价值》

《DDD落地：从美团抽奖平台，看DDD在大厂如何落地？》

《美团面试：微服务如何拆分？原则是什么？》

《DDD神药：去哪儿结合DDD，实现架构大调优》

《DDD落地：从网易新闻APP重构，看DDD的巨大价值》

《DDD落地：从阿里单据系统，看DDD在大厂如何落地？》

《DDD落地：有赞的生产项目，DDD如何落地？》

《DDD落地：从携程订单系统重构，看DDD的巨大价值》

《DDD落地：京东的微服务生产项目，DDD如何落地？》

《DDD落地：阿里供应链商品域，DDD如何落地？》

《240Wqps，美团用户中台， 如何使用DDD架构？》

大家可以先看前面的文章，再来看本篇，效果更佳。

另外，尼恩会结合一个工业级DDD实操项目，在第34章视频《DDD的学习圣经》中，给大家彻底介绍一下DDD的实操、COLA 框架、DDD的面试题。

DDD现在非常火爆，是有其巨大生产价值，经济价值的， 绝不仅仅是一套概念那么简单。

DDD的绝大价值，具体请参见以下视频：

从腾讯视频DDD重构案例，看看DDD极大价值

爱奇艺打赏业务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“是否被认证了”，而没有表达出“认证”这个过程。

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

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

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

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

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

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

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

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

DDD的优势

应用DDD的系统符合六边形架构，我们实现了以下目标：

• 独立于框架：架构不应该依赖某个外部的库或者框架，不应该被框架的结构所束缚；

• 独立于UI：前台展示的样式可能会随时发生变化，但是底层架构不应该随之而变化；

• 独立于底层数据源：软件架构不应该因为不同的底层数据存储而产生巨大改变；

• 独立于外部依赖：无论外部依赖如何变更、升级，业务的核心逻辑不应随之而大幅变化。

为实现以上目标，六边形架构（如洋葱架构、干净架构等）是个合适的选择。接下来，结合打赏具体业务实现，讲解如何实现这些目标。

先给出项目某个模块的代码包结构：

资源库：将资源库作为业务与数据的隔离层，屏蔽底层数据表细节，同时完成 PO 与 DO 的转化。DO 与 PO 的转化有利于领域层不直接依赖底层实现，便于后续更换底层实现或功能迁移。资源库接口定义在领域层，接口实现在基础设施层。

RPC：RPC 部分的结构拆分与资源库类似，区别在于存在领域服务。接口定义放在领域层，具体实现在基础设施层。

在遵循六边形架构的大原则下，其他边的拆分也变得清晰简单了，此处不再赘述。

通过以上实践，我们可以看到 DDD 在实际应用中的优势：

• 灵活性：基于领域驱动设计的系统具有较高的灵活性，可以轻松应对业务变化和需求变更。
• 可维护性：领域驱动设计将业务逻辑与技术实现分离，使得代码更具可读性和可维护性。
• 复用性：通过领域服务、聚合等概念，实现业务逻辑的复用，降低开发成本。
• 扩展性：领域驱动设计有助于提高系统的扩展性，方便引入新功能和模块。
• 降低耦合度：通过六边形架构，将业务层与底层技术层分离，降低系统耦合度，便于后续迭代和升级。

总之，应用 DDD 可以让我们更好地应对复杂多变的业务挑战，实现软件开发的卓越表现。在实际项目中，我们可以根据业务需求和场景，灵活运用 DDD 理念和相关架构，构建高质量、高可维护和易于扩展的软件系统。

几个关键问题

1、事务

在上文中“聚合”章节，我们讨论了事务，即在一次事务中只操作一个聚合实例。如果发现一次事务内的逻辑过多，可以考虑将部分逻辑剥离为独立的聚合，采用最终一致性。基于这个基础，应用层是最适合声明事务的层次。

2、查询

CQRS（命令查询职责分离）在 DDD 中是一种常见的模式。它将领域模型与查询功能分离，让复杂的查询摆脱领域模型的限制，以更简单的 DTO 形式展现查询结果。同时，CQRS 还分离了不同的数据存储结构，让开发者可以根据查询功能和需求更自由地选择数据存储引擎。具体实践可参考相关资料。

3、框架无关

六边形架构设计已实现与底层实现、框架、中间件无关。但还有一个较大的框架依赖，即 Spring。我们的解决方案是，在领域内使用的 Spring Bean 通过传参方式实现领域层与框架的解耦。

4、成本

在实践 DDD 时，成本是一个重要考虑因素，包括学习成本、改造成本、兼容成本等。在实际操作前，建议先评估好成本。

结束语

领域驱动设计（DDD）并非一套全新的特殊架构，而是一种应对软件复杂性的方法论。它基于面向领域建模，六边形架构，以及经过重构的项目代码，旨在实现高可维护性、高可扩展性、高可测试性和代码结构清晰。遵循这一方法，我们将能够更好地应对复杂多变的业务挑战，实现软件开发的卓越表现。

说在最后

DDD架构如何落地，是非常常见的面试题。

以上的内容，如果大家能对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。

在面试之前，建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》，并且在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

最终，让面试官爱到 “不能自已、口水直流”。offer， 也就来了。

当然，关于DDD，尼恩即将给大家发布一波视频 《第34章：DDD的学习圣经》， 帮助大家彻底穿透DDD。

技术自由的实现路径 PDF：

实现你的 架构自由：

《吃透8图1模板，人人可以做架构》

《10Wqps评论中台，如何架构？B站是这么做的！！！》

《阿里二面：千万级、亿级数据，如何性能优化？ 教科书级 答案来了》

《峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？》

《100亿级订单怎么调度，来一个大厂的极品方案》

《2个大厂 100亿级 超大流量 红包 架构方案》

… 更多架构文章，正在添加中

实现你的 响应式 自由：

《响应式圣经：10W字，实现Spring响应式编程自由》

这是老版本 《Flux、Mono、Reactor 实战（史上最全）》

实现你的 spring cloud 自由：

《Spring cloud Alibaba 学习圣经》

《分库分表 Sharding-JDBC 底层原理、核心实战（史上最全）》

《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系（史上最全）》

实现你的 linux 自由：

《Linux命令大全：2W多字，一次实现Linux自由》

实现你的 网络 自由：

《TCP协议详解 (史上最全)》

《网络三张表：ARP表, MAC表, 路由表，实现你的网络自由！！》

实现你的 分布式锁 自由：

《Redis分布式锁（图解 - 秒懂 - 史上最全）》

《Zookeeper 分布式锁 - 图解 - 秒懂》

实现你的 王者组件 自由：

《队列之王： Disruptor 原理、架构、源码 一文穿透》

《缓存之王：Caffeine 源码、架构、原理（史上最全，10W字 超级长文）》

《缓存之王：Caffeine 的使用（史上最全）》

《Java Agent 探针、字节码增强 ByteBuddy（史上最全）》

实现你的 面试题 自由：

4000页《尼恩Java面试宝典 》 40个专题

以上尼恩 架构笔记、面试题 的PDF文件更新，▼请到下面【技术自由圈】公号取 ▼