尼恩说在前面

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

谈谈你的DDD落地经验?

谈谈你对DDD的理解?

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

微服务如何拆分?

微服务爆炸,如何解决?

你们的项目,DDD是怎么落地实操的?

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

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

最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF,请关注本公众号【技术自由圈】获取,后台回复:领电子书

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

阿里DDD大佬:从0到1,带大家精通DDD

阿里大佬:DDD 落地两大步骤,以及Repository核心模式

阿里面试:让代码不腐烂,DDD是怎么做的?

阿里大佬: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 几点说明

- 说在最后

- 部分历史案例

腾讯视频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 的基本过程进一步展开来说,大体是以下三点:

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

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

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

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

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

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

说在最后

DDD架构如何落地,是是非常常见的面试题。

以上的内容,如果大家能对答如流,如数家珍,基本上 面试官会被你 震惊到、吸引到。

在面试之前,建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》,并且在刷题过程中,如果有啥问题,大家可以来 找 40岁老架构师尼恩交流。

最终,让面试官爱到 “不能自已、口水直流”。offer, 也就来了。

当然,关于DDD,尼恩即将给大家发布一波视频  《第34章:DDD的顶奢面经》, 帮助大家彻底穿透DDD。

图片

部分历史案例