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亿级超大流量红包架构方案》

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

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

文章来源:https://blog.csdn.net/crazymakercircle/article/details/135031513
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：veading@qq.com进行投诉反馈，一经查实，立即删除！

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

尼恩说在前面

文章目录

爱奇艺打赏业务DDD实践

价值

领域驱动设计是什么

DDD打赏业务实践

1、打赏业务简介

2、战略设计

六边形架构

3、战术设计

DDD的优势

几个关键问题

结束语

说在最后

技术自由的实现路径 PDF：

实现你的 架构自由：

实现你的 响应式 自由：

实现你的 spring cloud 自由：

实现你的 linux 自由：

实现你的 网络 自由：

实现你的 分布式锁 自由：

实现你的 王者组件 自由：

实现你的 面试题 自由：

实现你的架构自由：

实现你的响应式自由：

实现你的网络自由：

实现你的分布式锁自由：

实现你的王者组件自由：

实现你的面试题自由：