DDD领域驱动设计内容分享(十八)：从腾讯视频DDD重构之路，看DDD极大价值

目录

01 领域驱动

02 软件架构

03 架构映射

04 架构映射

05 效果评估

06 几点说明

---

01 领域驱动

1.1 DDD 简介

视频会员部门正在推进一个领域驱动的项目，期望运用 DDD 的一些理论，对会员技术体系的进行全面梳理。内容作为其中的一个子领域，也希望借助 DDD 的一些方法进行整个体系的建设：

• 复杂度：业务复杂性（包括播放、购买、活动、内容展示、内容互动等全场景），以及技术复杂性（如业务规则、模块繁多、高并发、信息安全等），需要全面考虑。

• 跨部门合作：目前的会员内容体系，涉及会员、直播中台、腾讯云、安平审核等多个部门，是一个典型的跨部门合作项目。

• 体系梳理：会员业务涵盖内容展示、内容互动、内容合作和内容创新四个方面。

• 领域模型：本文将重点借助领域图，将整个会员内容体系以直观的方式展现出来。

DDD 的核心方法，总结起来是以下四点：

1.2 领域建模

在理解产品需求的基础上，从中提取出核心概念，然后建立起核心概念的逻辑结构，概念的逻辑结构即领域模型，通常可以用领域图或 ER 图来表示。领域模型有助于我们以一种抽象的视角来理解复杂业务。

对于复杂大系统，DDD 给出的基本操作方法就是<大分形>，即大而化之、分而治之、形而上之。将这个方法应用在内容体系上，可以做一个初步的领域建模。

1.3 领域建模-例1

将上述方法应用于视频会员内容体系，进行初步的领域建模。针对会员内容体系业务梳理，以内容为核心，划分为以下四个部分：

• 内容展示：包括频道页、一起看底层页的 3tab、端外频道页等。

• 内容互动：涉及一起看业务、观看剧集、聊天、赠票、连麦、陪看等。

• 内容合作：涵盖小说、漫画、知识付费等。

• 内容创新：如 NFT 等。

1.4 领域建模-例2

02 软件架构

2.1 定义架构

软件架构并无明确的定义，但我们可以通过【结构、架构特性、架构决策和设计原则】来阐述。

• 结构：指的是系统的架构风格类型，如分层架构、微服务架构、管道架构、事件驱动架构等。

• 架构特征：指的是系统必须支持的功能，如可用性、可扩展性、容错性、性能、可维护性等。

• 架构决策：是一组构建系统的规则，例如规定表现层只能通过逻辑层访问持久层。

• 设计原则：是构建系统的指导原则，如采用服务间的异步消息传递以提高性能。

相较而言，架构决策的约束力比设计原则更强。

2.2 架构特征

常见的架构特征有两大类，运营性架构与结构性架构，其定义如下：

2.3 架构特征

除开上述的运营性和结构性架构特性，我们在过去的系统开发实践中，似乎一直忽视了一个重要的架构特性——模块化。模块化可以被视为一种隐性的架构特性。

下面一段引用自《软件架构》的话，很好地解释了模块化的概念：

关于软件架构的用语中有95%以上都在称颂“模块化”，而关于如何实现“模块化”的用语却少之又少。-Glenford J.Myers(1978年)

不同的平台提供了不同的代码重用机制，但所有平台都支持以某种方式将相关代码分组到模块中。尽管模块化在软件架构中具有通用性，但却一直没有统一的定义。从 Myers 的引言中可以看出，这是一个历史悠久的问题。

对于架构师来说，了解模块化及其多种形式，在开发平台中至关重要。许多分析架构的工具（如度量指标、适应度函数和可视化）都依赖于模块化概念。模块化是一种组织原则。如果架构师在设计系统时没有关注各个部分如何相互连接，那么最终构建的系统必将出现问题。从物理学的角度看，软件系统是对趋于熵（或无序）的复杂系统进行建模，必须向物理系统添加能量以保持秩序。软件系统也是如此：架构师必须不断消耗精力以确保良好的结构稳定性。

保持良好的模块化体现了我们对一种隐式架构特性的定义：几乎没有项目要求架构师确保良好的模块化划分，并以模块化为主题与项目成员进行沟通。而可持续的代码需要秩序和一致性。

我们用模块化来描述代码的逻辑分组，可以是面向对象语言中的一组类，也可以是结构化语言和函数式语言中的函数。大多数编程语言都提供了模块化的机制（如 Java 中的包（package）、NET 中的命名空间（namespace）等。开发人员通常使用模块作为将相关代码分组在一起的一种方式。

模块化对架构师至关重要，研究人员创建了各种跨语言的度量标准来帮助架构师理解模块化。我们重点关注三个关键概念：内聚性、耦合性和共生性。

通过对模块化特性的深入了解，架构师可以更好地应对复杂多样的系统架构挑战，确保软件系统的稳定性和可持续发展。在实际项目中，了解并践行模块化原则，对于提升系统质量及降低维护成本具有重要意义。

内聚性及其度量：

耦合性及其度量：

共生性及其度量：

统一耦合性与共生性：

2.4 架构风格及度量

平时的实际工作中，常见的是以下六种架构：

分层架构。管道架构。微内核架构。微服务架构。事件驱动架构。编制驱动架构。

我们可以通过以下特征来对各个架构进行评级：

03 架构映射

3.1 DDD 过程模型

作为开发，我们工作的本质就是把一个产品需求转化成一个可以运行的系统，中间涉及产品设计、领域建模、架构设计、详细设计、代码编写、测试等步骤。

如果不考虑编码过程，就 DDD 的基本过程进一步展开来说，大体是以下三点：

1. 基于产品需求，提取核心概念，并构建核心概念的逻辑结构，即领域模型。领域模型通常可以用领域图或 ER 图表示。领域模型帮助我们以抽象视角理解复杂业务，但仅限于理解业务。我们最终目标是将领域模型转化为实际可运行的系统。

2. 从领域模型到代码实现，通常需要通过系统架构进行衔接。将领域模型映射为系统架构至关重要。通常采用分层微服务架构，将领域模型中的概念分解到架构的各层。

3. 在拥有领域模型和系统架构的基础上，对各个模块进行详细设计，包括模块流程、数据结构设计、数据库表设计等。完成这一步后，即可启动编码工作。

在整个 DDD 开发流程中，我们需要不断迭代和优化领域模型、系统架构和模块设计，以确保最终实现的系统能够满足业务需求并具备良好的可维护性。在实际项目中，合理运用 DDD 开发流程模型，有助于提高开发效率，降低维护成本，并使系统更具可扩展性。通过遵循这一流程，我们可以更好地应对业务的变化和挑战，为客户提供高质量的软件产品。

为便于理解，以下是我自己梳理的一个 DDD 过程模型：

3.2 架构映射

在过去的项目中，很多时候我们在开始系统架构设计之前并没有进行领域建模。这主要是因为：

1. 业务本身并不复杂，例如核心实体只有一个，然后仅需针对这个核心实体进行属性增删改查操作。大部分管理系统开发都属于这种情况。产品的交互和视觉设计基本可以替代领域建模，尤其在腾讯的研发体系中，我们通常根据产品 UI 稿来设计系统架构。

2. 对于一些特别复杂的业务，我们需要在理解产品需求的基础上，提取核心概念构建领域模型，并将领域模型中的概念分解到系统架构的各层和模块。架构映射就是将领域模型映射到系统架构的过程。

3. 在进行架构映射时，我们需要关注以下几个方面：

• a. 分析业务需求，找出核心概念，构建领域模型。领域模型可以帮助我们更好地理解业务，为后续架构设计提供指导。

• b. 将领域模型分解为系统架构的各层和模块。这样可以将复杂的业务逻辑分解为更易于管理和维护的模块。

• c. 在架构设计中充分考虑系统性能、可扩展性、安全性等因素，确保系统能够稳定运行并适应业务发展。

• d. 随着业务的发展和变化，不断优化和调整架构，使其保持与业务需求的匹配。

架构映射，以视频一起为例：

04 架构映射

4.1 DDD 与重构

领域驱动设计的焦点在于系统设计阶段，但同样重视重构。在一定程度上，软件工程师仍是手工艺者，软件开发没有绝对的银弹，重构在系统成长过程中是不可或缺的调整手段。

因此，我们无需迷信所谓的银弹，也不必担心过度设计或设计不足，通过多次重构迭代，让合适的设计逐步浮现。

4.2 一起看的技术债

视频一起看，经过几年不断的功能开发，已经堆砌了比较多的模块，而且是由两个跨部门的团队一起开发的，整体上缺乏统一设计，技术债务积累较多，亟需来一次整体重构。

4.3 发起重构

整个重构规划如下：

4.4 架构重构

在架构方面，分层不明确，下层服务过于理解业务逻辑，存在下层调用上层的问题。部分接口或函数职责重复，可以合并或归为一处。重复代码和逻辑较多，缺乏公共抽象。

老系统架构图：room_adapter 是结构瓶颈。

具体的解决办法分为两点：

1. 明确架构分层，降低模块间不必要的耦合；

   严格遵守分层架构原则，上层服务可调用下层服务，下层服务不涉及业务逻辑。如上下层服务需交互，可通过逻辑解耦方式实现，如消息队列或中转。

2. 调整领域划分，合理分配功能，避免模块过大或过小；

   重新规划领域划分，使功能分配更合理，各模块专注专属领域能力，便于后续开发与维护。

重构前后架构对比：

4.5 逻辑重构

涉及较多业务逻辑的部分，重构方法主要包括以下两点：

1. 剥离非核心逻辑子域，确保业务主流程可读性；

   将非核心业务逻辑从主流程中抽取出来，作为子域进行封装，提高可读性和可维护性。

2. 提取公共组件，消除代码复制，提高复用性；

下面是一个房间重构的例子：

以 room_adapter 为例，因为属于业务适配层，掺杂过多特殊业务逻辑，导致可读性和可维护性差。

通过梳理服务流程，将非核心业务逻辑剥离为子域，并封装为 trpc 拦截器，确保业务主流程的可维护性。

在进一步分析系统重构完之后的效果时，我们先补充一点架构方面的知识点，这可以更方便地以一种量化的方式来评估重构效果。

05 效果评估

这部分通过介绍视频会员今年做的一个系统重构项目，结合上面的知识点，对这个项目做一整体量化分析。

5.1 问题与目标

一起看房间系统，这是一个重构项目，如果说明这个项目的意义，通常的结构就是“问题-目标-方案-效果”。

5.2 效果的定性说明

在系统架构层面，重构前后的架构对比：

重构前后，到底有什么效果，我们可以定性来说，比如：

• 重构前：单体架构，难维护难扩展；

• 重构后：微服务架构，内核简单，易于扩展。

• 重构前：功能堆砌，没有整体规划；

• 重构后：架构清晰，产品功能有序扩展。

对于非技术同学（产品、运营）来说，定性说明可能更容易理解，但定性说明本身比较随意，任何一个重构都可以讲出以上这些好处，所以没有区分度。

5.3 效果的量化分析

在定性说明的基础上，有必要做进一步的量化分析，这样效果就更有说服力。

• 在架构层面，重构前后的改进

我们可以利用上一节的架构风格及特征参数，从而能够做出量化分析，这样得出的结论就更有说服力。

• 重构前系统：可以看做是微内核模式；

• 重构后系统：可以看做是微服务模式。

这样我们就可以对比重构前系统与重构后系统的区别，可以看到重构后的系统在可测试性、扩展性及模块化方面都有明显改进。

• 在模块层面，重构前后的改进

• 重构前：room adapter 模块包含了太多低耦合逻辑，除房间业务逻辑外，还有定时任务、房间回调、进房审批鉴权、消息发送。

• 重构后：room_adapter 模块只保留房间业务逻辑，其他逻辑按高内聚低耦合拆分为独立小模块。

• 在代码层面，重构前后在四个维度（代码规范、千行问题、圈复杂度、千行超标复杂度）上的改进：

• 代码量方面，重构前代码量约 4w 行，重构后 1.8w 行，降幅55%

• 性能方面，重构后 Top4 接口耗时都有明显优化，平均耗时降低45%左右

• 成本方面，通过下图趋势线可以看出，Top4 成本均呈下降趋势，其中 PCG-123 和日志服务 CLS 成本降幅明显，达到40%左右

5.4 设计关键点

这里不准备长篇大论，通过以下几个关键设计点，从整体上了解一下【视频一起看房间系统】：

• 系统架构

• 核心数据结构

• 技术与业务指标

关键技术指标：请求量 QPS 峰值：约3万/QPS，Redis 存储占用量：11.16GB；

关键业务指标：线上房间总数：约6k+，其中用户房约3K，系统房3k，运营房0.25k。

06 几点说明

在开发领域耕耘多年，我一直被以下几个问题所困扰。现在，我想针对这些问题分享自己的见解并进行深入探讨：

• 当我们描述系统架构时，通常会提及高性能、可扩展性、可观察性等关键词。然而，我们缺乏一个统一的量化分析框架，以便不同架构风格之间进行对比。本文将尝试解决这一问题，使各种架构风格具有可比性；

• 领域建模和架构设计之间的关系是什么，本文提出“架构映射”的概念，试图建立二者之间的转换关系；

• 架构理论与架构设计的实践相结合，试图给出一套可操作、能落地、能量化对比的设计方法；

• 做过很多重构，重构前后系统效果的说明，通常会采用定性描述，或者列举单点说明，比如性能、扩展性等，如何以一种可量化的整合的方式说明重构的效果。