# 关注并星标腾讯云开发者
# 每周3 | 谈谈我在腾讯的架构设计经验
# 第10期 | 领域驱动设计方法——核心概念与关键方法
开宗明义，DDD 是一种技术方法论，不是某种具体的技术架构，也不是某种编程框架层面的东西。如果你面临的任务是把一个经过多年开发迭代从而变的异常繁杂的系统，重新梳理重构为一个结构合理、职责清晰的新系统，那么 DDD 作为一种技术方法论可以一展身手。有同学找到我说，在他看来 DDD 是解决效率问题的，我说 DDD 解决的是复杂度问题。复杂度来源于两个方面：技术复杂度（例如安全、高性能、高并发、高可用性等）和业务复杂度。业务复杂度与技术复杂度并非完全独立，二者混合在一起产生的化合作用，更让系统的复杂度变得不可预期，二者变化维度、周期也不同，再加上团队规模和人员流动等因素，加剧了架构腐化和系统复杂性。根据康威定律，“设计系统的架构受制于产生这些设计的组织的沟通结构。” 我们可以把康威定律正着用或者反正用，调整不了组织架构那就调整业务架构，尽可能让两者匹配起来。技术视角与业务视角有所区别，但也要找到结合点，最好是融合起来，让两者在底层逻辑上保持一致。把业务架构、系统架构、组织架构三者完美地结合起来，某种程度上说，这就是领域驱动。领域驱动声称自己处理的是“大比例结构”，详细考察领域驱动的经典文献，我们可以看出，DDD 实际上是通过一些诸如“隐喻、分层、抽象、提炼”的手法，把一个复杂的大系统大而化小，分而治之。例如，通过使用“隐喻、分层、抽象、提炼”的手法，将一个处于混沌状态的系统建模为一种清晰的结构，用 DDD 的术语来说，就是领域建模或战略建模。DDD 为复杂度而生，同时也提供了一些应对复杂度的具体方法，比如：通过架构设计来分离业务复杂度和技术复杂度；通过限界上下文将一个大系统切分为若干高内聚低耦合的子领域；通过领域模型对业务领域的知识进行抽象。但是，我们期望也不能太高。总的来说，DDD 能解决一些问题，但 DDD 并不是银弹，在最好的情况下，DDD 也只是一个部分可用工程解，而不会是一个完美无缺的理论解。复杂度也许永远不能消除，但我们可以分析复杂度，进而管理复杂度。软件复杂度可以分为业务复杂度与技术复杂度。我们可以从这两个方面来展开分析。比如，视频会员业务的业务复杂度就很高。比如，电脑的操作系统的技术复杂度就很高。软件复杂度是一个建模问题，建模即是要搭建一个符合逻辑的概念体系，这个概念体系就是模型 Model。在领域驱动的经典书籍里，对领域 domain 并没有一个正式定义，通过下面两个线索，我们可以分析出领域实际上就是模型：1）在书中可以找到的一句话，把领域和模型关联起来：“这些用户应用软件的问题区域就是软件的领域。软件开发中复杂的信息可能超乎想象，模型正是解决此类问题的工具。”2）书中的一个图示：领域层（或模型层）， 从这里可以看出领域=模型，两者至少是可以相互替换的。前面一部分内容讲了 DDD 的基本概念，接下来进入 DDD 的实战部分，分为四个部分：战略建模、战术建模、统一语言、建模工具，每个部分沿三个点来展开：操作方法、案例分析、一句话总结。
通读领域驱动的经典著作，在消化吸收再创造的基础上，我们可以总结出建模大型系统的四种方法：- 使用隐喻，比如电动汽车其实就是一台电脑装了四个轮子。
- 把大型系统提炼为一个抽象结构，例如，冯诺依曼计算机=IO+CPU+Memory。
- 战略精炼：对核心域进一步萃取，过滤掉不必要的杂质，使得其方向更清晰，内容更准确、内核更精干。
通过隐喻与分层两个手法，可以很快看清腾讯视频会员技术架构：还是视频会员技术架构的例子，只是换了几个不同的视角来看，视角不同答案也就不同。碰到一个复杂的大系统，不要害怕，不管三七二十一，先用战略建模八字手法“隐喻、分层、精炼、抽象”分析一番。分析完并理清上面的概念之后，对整个视频媒资系统，基本就是成竹在胸。本文最开始我就讲过，要把业务架构和技术架构结合起来。对于视频媒资系统，我们可以把业务层和领域层结合起来思考，业务层反映业务逻辑，是一个产品视角，而领域层反映技术逻辑，是一个技术视角。在操作方法上仍类似：
有同学把“隐喻、分层、精炼、抽象”说成是八字箴言：
- 构造块：在类、对象、组合、继承等层次上对系统进行设计。
- 柔性设计：列举了一些设计原则，类似于常见的软件设计原则，只是换了一种说法。例如通过明确概念、避免概念过载、处理副作用等做法，得到的是一个高内聚低耦合的设计。
案例：江湖派与学院派在战术建模方面的对比（构造块）案例：江湖派与学院派在战术建模方面的对比（柔性设计）
UBIQUITOUS LANGUAGE，有的书翻译为通用语言，有的书翻译为统一语言，其核心要点为：✓ 将领域模型作为统一语言的核心，基于模型进行沟通业务领域有业务领域的语言，不同业务有不同语言。下面是腾讯动漫的一个例子。以下是几个技术领域的例子，不同层次有不同层次的语言。在《领域驱动设计·软件核心复杂性应对之道》这本书里，明确提到了设计模式，这可以看做比编程语言更高一个层级的语言，提高了思维的抽象层次。《微服务架构设计模式》和《面向模式的软件架构》在架构设计层面建立起了一套完整的模式语言，比设计模式再高一个层级。
- 江湖派没有规范的工具，文献里面主要是，限界上下文和上下文图映射图。
对比一下，江湖派可以说非常简陋，而学院派则提供了完整的工具箱。案例：用 UML 建模复杂业务流程（一起看预鉴权流程）- “昨夜西风凋碧树,独上高楼,望尽天涯路。” 此第一境也。
- “ 衣带渐宽终不悔,为伊消得人憔悴。” 此第二境也。
- “ 众里寻他千百度,蓦然回首,那人却在,灯火阑珊处。”此第三境也。
我从12年开始接触领域驱动设计，到现在已经十年了，对 DDD 的理解也经历了一个禅宗式的参悟的过程：参禅之初，看山是山，看水是水；禅有悟时，看山不是山，看水不是水；禅中彻悟，看山仍然山，看水仍然是水。世间学问，在王国维看来，可以分为两类，一类是可爱而不可信，一类是可信而不可爱。江湖一派的东西，通常是可爱而不可信，因为灵活所以怎么讲都不会错。而学院一派则是可信而不可爱，因为严谨繁琐从而不够有趣。可爱还是可信，江湖派还是学院派，如何取舍，王国维一句“余知真理，而余又爱其谬误”，讲出了智慧。架构设计是实践重要还是方法重要？欢迎评论。我们将选取1则最有价值的评论，送出腾讯云开发者社区定制笔记本1个（见下图）。11月29日中午12点开奖。
📢📢欢迎加入腾讯云开发者社群，社群专享券、大咖交流圈、第一手活动通知、限量鹅厂周边等你来~