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 几点说明
在开发领域耕耘多年，我一直被以下几个问题所困扰。现在，我想针对这些问题分享自己的见解并进行深入探讨：
-
当我们描述系统架构时，通常会提及高性能、可扩展性、可观察性等关键词。然而，我们缺乏一个统一的量化分析框架，以便不同架构风格之间进行对比。本文将尝试解决这一问题，使各种架构风格具有可比性；
-
领域建模和架构设计之间的关系是什么，本文提出“架构映射”的概念，试图建立二者之间的转换关系；
-
本文将研究如何将架构理论与实际架构设计相结合，以提供一套具有操作性、可行性且能进行量化对比的设计方法；
-
做过很多重构，重构前后系统效果的说明，通常会采用定性描述，或者列举单点说明，比如性能、扩展性等，如何以一种可量化的整合的方式说明重构的效果。
说在最后
DDD架构如何落地，是是非常常见的面试题。
以上的内容，如果大家能对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。
在面试之前，建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》，并且在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。
最终，让面试官爱到 “不能自已、口水直流”。offer， 也就来了。
当然，关于DDD，尼恩即将给大家发布一波视频 《第34章：DDD的顶奢面经》， 帮助大家彻底穿透DDD。
尼恩技术圣经系列PDF
- 《NIO圣经：一次穿透NIO、Selector、Epoll底层原理》
- 《Docker圣经：大白话说Docker底层原理，6W字实现Docker自由》
- 《K8S学习圣经：大白话说K8S底层原理，14W字实现K8S自由》
- 《SpringCloud Alibaba 学习圣经，10万字实现SpringCloud 自由》
- 《大数据HBase学习圣经：一本书实现HBase学习自由》
- 《大数据Flink学习圣经：一本书实现大数据Flink自由》
- 《响应式圣经：10W字，实现Spring响应式编程自由》
- 《Go学习圣经：Go语言实现高并发CRUD业务开发》
……完整版尼恩技术圣经PDF集群，请找尼恩领取
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓