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

尼恩说在前面

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

谈谈你的DDD落地经验？

谈谈你对DDD的理解？

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

微服务如何拆分？

微服务爆炸，如何解决？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文章目录

- 尼恩说在前面
- 腾讯视频DDD重构之路
- 01 领域驱动
- - 1.1 DDD 简介
  - 1.2 领域建模
  - 1.3 领域建模-例1
  - 1.4 领域建模-例2
- 02 软件架构
- - 2.1 定义架构
  - 2.2 架构特征
  - 2.3 架构特征
  - 2.4 架构风格及度量
- 03 架构映射
- - 3.1 DDD 过程模型
  - 3.2 架构映射
- 04 架构映射
- - 4.1 DDD 与重构
  - 4.2 一起看的技术债
  - 4.3 发起重构
  - 4.4 架构重构
  - 4.5 逻辑重构
- 05 效果评估
- - 5.1 问题与目标
  - 5.2 效果的定性说明
  - 5.3 效果的量化分析
  - 5.4 设计关键点
- 06 几点说明
- 说在最后
- 尼恩技术圣经系列PDF

腾讯视频DDD重构之路

作者：刘啸南

DDD 的指导思想很多时候较为晦涩，与实际业务场景下的架构设计往往难以紧密结合。本文尝试通过引入架构映射等方法，将二者相互融合，旨在提供一套量化的评估体系，并通过腾讯视频一起看系统的实践案例阐述如何运用。

本文将以腾讯视频一起看系统的架构重构实践为例，展示一套具有参考价值的领域建模、架构设计与量化评估标准。

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 的基本过程进一步展开来说，大体是以下三点：

基于产品需求，提取核心概念，并构建核心概念的逻辑结构，即领域模型。领域模型通常可以用领域图或 ER 图表示。领域模型帮助我们以抽象视角理解复杂业务，但仅限于理解业务。我们最终目标是将领域模型转化为实际可运行的系统。
从领域模型到代码实现，通常需要通过系统架构进行衔接。将领域模型映射为系统架构至关重要。通常采用分层微服务架构，将领域模型中的概念分解到架构的各层。
在拥有领域模型和系统架构的基础上，对各个模块进行详细设计，包括模块流程、数据结构设计、数据库表设计等。完成这一步后，即可启动编码工作。

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

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

3.2 架构映射

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

业务本身并不复杂，例如核心实体只有一个，然后仅需针对这个核心实体进行属性增删改查操作。大部分管理系统开发都属于这种情况。产品的交互和视觉设计基本可以替代领域建模，尤其在腾讯的研发体系中，我们通常根据产品 UI 稿来设计系统架构。
对于一些特别复杂的业务，我们需要在理解产品需求的基础上，提取核心概念构建领域模型，并将领域模型中的概念分解到系统架构的各层和模块。架构映射就是将领域模型映射到系统架构的过程。
在进行架构映射时，我们需要关注以下几个方面：

a. 分析业务需求，找出核心概念，构建领域模型。领域模型可以帮助我们更好地理解业务，为后续架构设计提供指导。
b. 将领域模型分解为系统架构的各层和模块。这样可以将复杂的业务逻辑分解为更易于管理和维护的模块。
c. 在架构设计中充分考虑系统性能、可扩展性、安全性等因素，确保系统能够稳定运行并适应业务发展。
d. 随着业务的发展和变化，不断优化和调整架构，使其保持与业务需求的匹配。

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

04 架构映射

4.1 DDD 与重构

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

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

4.2 一起看的技术债

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

4.3 发起重构

整个重构规划如下：

4.4 架构重构

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

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

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

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

严格遵守分层架构原则，上层服务可调用下层服务，下层服务不涉及业务逻辑。如上下层服务需交互，可通过逻辑解耦方式实现，如消息队列或中转。
调整领域划分，合理分配功能，避免模块过大或过小；

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

重构前后架构对比：

4.5 逻辑重构

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

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

将非核心业务逻辑从主流程中抽取出来，作为子域进行封装，提高可读性和可维护性。
提取公共组件，消除代码复制，提高复用性；

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

以 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 几点说明

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

当我们描述系统架构时，通常会提及高性能、可扩展性、可观察性等关键词。然而，我们缺乏一个统一的量化分析框架，以便不同架构风格之间进行对比。本文将尝试解决这一问题，使各种架构风格具有可比性；
领域建模和架构设计之间的关系是什么，本文提出“架构映射”的概念，试图建立二者之间的转换关系；
本文将研究如何将架构理论与实际架构设计相结合，以提供一套具有操作性、可行性且能进行量化对比的设计方法；
做过很多重构，重构前后系统效果的说明，通常会采用定性描述，或者列举单点说明，比如性能、扩展性等，如何以一种可量化的整合的方式说明重构的效果。