本篇文章将通过腾讯视频一起看系统的架构重构实践，给出一套可供参考的领域建模、架构设计与量化评估准则。

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

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

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

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

将上面的方法应用在视频会员内容体系上，可以做一个初步的领域建模。针对会员内容体系业务梳理，以内容为核心，共分为4块：

• 内容展示：如频道页，一起看底层页3tab，端外频道页等。

• 内容互动：一起看业务，看剧，聊天，赠票，连麦，陪看等。

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

• 内容创新：NFT 等。

软件架构，其实没有一个明确定义，但可以通过【结构、架构特征、架构决策和设计原则】来描述。

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

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

除了上面定义的那些运营性与结构性架构特征外，我们过往的系统开发实践中，似乎一直忽略了很重要的架构特征，即“模块化”，这一架构特征可以看做是隐式的架构特征。

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

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

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

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

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

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

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

内聚性及其度量：

耦合性及其度量：

共生性及其度量：

统一耦合性与共生性：

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

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

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

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

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

过往工作，大部分时候，我们一上来就开始系统架构设计，并没有领域建模这一步，究其原因主要是：

只有对于一些特别复杂的业务，在理解产品需求的基础上，从中提取出核心概念构成领域模型，然后把领域模型中的概念分解到系统架构中的各层和各模块中去。架构映射即是把领域模型映射到系统架构。

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

领域驱动设计的重点在系统设计阶段，但领域驱动设计同样将重构作为重要内容。某种程度而言，软件工程师仍然是手工业者，软件开发仍然没有银弹，重构仍然是软件在生长过程中不可或缺的调校手段。

因此，我们也不用迷信什么银弹，也不必忌讳什么过度设计与设计不足，通过多次重构迭代，让正确的设计逐步显现。

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

整个重构规划如下：

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

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

严格遵守分层架构，上层服务可以调用下层服务，下层服务禁止调用上层服务，下层服务不关心业务逻辑。如果上下层服务需要发生交互，通过逻辑解耦的方式进行，如消息队列/中转。

通过重新调整领域划分，使得功能分布上更为合理，各个模块专注于专属领域相关能力，更利于后续开发和维护。

重构前后架构对比：

这部分涉及较多业务逻辑，方法上主要是以下两点：

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

以 room_adapter 为例，因为属于业务适配层，掺杂了太多的特殊业务逻辑，导致代码可读性，可维护性很差；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

做开发多年，一直有一些问题困扰着自己，本文主要想对以下几个问题做出自己的理解和探索：