DDD领域驱动设计内容分享(十七)：从腾讯视频架构重构，看DDD的概念与方法
目录
DDD与复杂度
理论之后如何实战
战略建模
操作方法
案例分析
战术建模
操作方法
案例分析
统一语言
操作方法
案例分析
建模工具
操作方法
案例分析
DDD与复杂度
开宗明义，DDD 是一种技术方法论，不是某种具体的技术架构，也不是某种编程框架层面的东西。
如果你面临的任务是把一个经过多年开发迭代从而变的异常繁杂的系统，重新梳理重构为一个结构合理、职责清晰的新系统，那么 DDD 作为一种技术方法论可以一展身手。
-
DDD 为复杂度而生
有同学找到我说，在他看来 DDD 是解决效率问题的，我说 DDD 解决的是复杂度问题。复杂度来源于两个方面：技术复杂度（例如安全、高性能、高并发、高可用性等）和业务复杂度。业务复杂度与技术复杂度并非完全独立，二者混合在一起产生的化合作用，更让系统的复杂度变得不可预期，二者变化维度、周期也不同，再加上团队规模和人员流动等因素，加剧了架构腐化和系统复杂性。
-
DDD 要达成什么目标
根据康威定律，“设计系统的架构受制于产生这些设计的组织的沟通结构。” 我们可以把康威定律正着用或者反正用，调整不了组织架构那就调整业务架构，尽可能让两者匹配起来。技术视角与业务视角有所区别，但也要找到结合点，最好是融合起来，让两者在底层逻辑上保持一致。
把业务架构、系统架构、组织架构三者完美地结合起来，某种程度上说，这就是领域驱动。
-
DDD 的关键方法
领域驱动声称自己处理的是“大比例结构”，详细考察领域驱动的经典文献，我们可以看出，DDD 实际上是通过一些诸如“隐喻、分层、抽象、提炼”的手法，把一个复杂的大系统大而化小，分而治之。例如，通过使用“隐喻、分层、抽象、提炼”的手法，将一个处于混沌状态的系统建模为一种清晰的结构，用 DDD 的术语来说，就是领域建模或战略建模。
-
DDD 不是银弹
DDD 为复杂度而生，同时也提供了一些应对复杂度的具体方法，比如：通过架构设计来分离业务复杂度和技术复杂度；通过限界上下文将一个大系统切分为若干高内聚低耦合的子领域；通过领域模型对业务领域的知识进行抽象。
但是，我们期望也不能太高。总的来说，DDD 能解决一些问题，但 DDD 并不是银弹，在最好的情况下，DDD 也只是一个部分可用工程解，而不会是一个完美无缺的理论解。
理论之后如何实战
-
核心概念
-
复杂度
复杂度也许永远不能消除，但我们可以分析复杂度，进而管理复杂度。软件复杂度可以分为业务复杂度与技术复杂度。我们可以从这两个方面来展开分析。比如，视频会员业务的业务复杂度就很高。比如，电脑的操作系统的技术复杂度就很高。
-
江湖派与学院派
-
结合点是 Model
软件复杂度是一个建模问题，建模即是要搭建一个符合逻辑的概念体系，这个概念体系就是模型 Model。
-
领域即模型
在领域驱动的经典书籍里，对领域 domain 并没有一个正式定义，通过下面两个线索，我们可以分析出领域实际上就是模型：
1）在书中可以找到的一句话，把领域和模型关联起来：“这些用户应用软件的问题区域就是软件的领域。软件开发中复杂的信息可能超乎想象，模型正是解决此类问题的工具。”
2）书中的一个图示：领域层（或模型层）， 从这里可以看出领域=模型，两者至少是可以相互替换的
领域驱动与模型驱动之间的关系，可以总结如下：
前面一部分内容讲了 DDD 的基本概念，接下来进入 DDD 的实战部分，分为四个部分：战略建模、战术建模、统一语言、建模工具，每个部分沿三个点来展开：操作方法、案例分析、一句话总结。
战略建模
-
操作方法
通读领域驱动的经典著作，在消化吸收再创造的基础上，我们可以总结出建模大型系统的四种方法：
-
使用隐喻，比如电动汽车其实就是一台电脑装了四个轮子。
-
把大型系统从逻辑上切分成若干层，分而治之。
-
把大型系统提炼为一个抽象结构，例如，冯诺依曼计算机=IO+CPU+Memory。
-
战略精炼：对核心域进一步萃取，过滤掉不必要的杂质，使得其方向更清晰，内容更准确、内核更精干。
-
案例分析
案例：腾讯视频会员技术架构
通过隐喻与分层两个手法，可以很快看清腾讯视频会员技术架构：
-
隐喻：支撑域+核心域+通用域
-
分层：表示层+应用层+设施层
还是视频会员技术架构的例子，只是换了几个不同的视角来看，视角不同答案也就不同。
案例：视频媒资系统（产品架构）
碰到一个复杂的大系统，不要害怕，不管三七二十一，先用战略建模八字手法“隐喻、分层、精炼、抽象”分析一番。
例如对视频媒资系统的产品架构可以做下面的分析：
-
隐喻：生命周期（预热期+更新期+长尾期）
-
隐喻：时间线
-
分层：流程层+工具层+基建层
-
隐喻：如影、星海
-
精炼：制+播+销
-
精炼：内容生产+内容消费
-
抽象：IAAS+PAAS
-
抽象：PGC+UGC
分析完并理清上面的概念之后，对整个视频媒资系统，基本就是成竹在胸。
案例：视频媒资系统（技术架构）
对视频媒资系统的技术架构可以做同样的分析：
-
隐喻：生命周期（预热期+更新期+长尾期）
-
隐喻：时间线
-
分层：流程层+工具层+基建层
-
精炼：制+播+销
-
精炼：内容生产+内容消费
-
抽象：IAAS+PAAS
-
抽象：PGC+UGC
案例：视频媒资系统（融合视角）
本文最开始我就讲过，要把业务架构和技术架构结合起来。
对于视频媒资系统，我们可以把业务层和领域层结合起来思考，业务层反映业务逻辑，是一个产品视角，而领域层反映技术逻辑，是一个技术视角。在操作方法上仍类似：
-
分层：业务层+领域层+基础层
-
精炼：内容生产+内容消费
-
抽象：IAAS+PAAS
战术建模
-
操作方法
战术建模怎么操作，书本上的讲法：
-
构造块：在类、对象、组合、继承等层次上对系统进行设计。
-
柔性设计：列举了一些设计原则，类似于常见的软件设计原则，只是换了一种说法。例如通过明确概念、避免概念过载、处理副作用等做法，得到的是一个高内聚低耦合的设计。
-
案例分析
案例：江湖派与学院派在战术建模方面的对比（构造块）
案例：江湖派与学院派在战术建模方面的对比（柔性设计）
统一语言
-
操作方法
UBIQUITOUS LANGUAGE，有的书翻译为通用语言，有的书翻译为统一语言，其核心要点为：
✓ 一个团队一种语言，语言统一才能沟通
✓ 将领域模型作为统一语言的核心，基于模型进行沟通
-
案例分析
案例：产品语言的例子
业务领域有业务领域的语言，不同业务有不同语言。下面是腾讯动漫的一个例子。
案例：技术语言的例子
以下是几个技术领域的例子，不同层次有不同层次的语言。在《领域驱动设计·软件核心复杂性应对之道》这本书里，明确提到了设计模式，这可以看做比编程语言更高一个层级的语言，提高了思维的抽象层次。
《微服务架构设计模式》和《面向模式的软件架构》在架构设计层面建立起了一套完整的模式语言，比设计模式再高一个层级。
案例：商业语言的例子（商业模式语言）
下面是用商业模式画布来描述瑞幸咖啡的商业模式：
建模工具
-
操作方法
建模工具方面：
-
江湖派没有规范的工具，文献里面主要是，限界上下文和上下文图映射图。
-
学院派最常用的是 UML，有非常多的图。
对比一下，江湖派可以说非常简陋，而学院派则提供了完整的工具箱。
-
案例分析
案例：UML 建模示例图
案例：一篇专利中的 UML 图型
案例：用 UML 建模复杂业务流程（一起看预鉴权流程）
