中台过气、微服务回归单体，DDD的意义何在？_DDD

2015年之后，随着云原生、微服务、大中台等一系列技术名词诞生的同时，还有一个耳熟能详的名词“领域驱动”也开始被捧上神坛。笔者初次听到领域驱动是参加一个技术分享会，当时给我的直观感受就是：好像说了什么，但又好像什么都没说，很多概念很"形而上学" ，在天空中飘啊飘，无法落地。
十年过去了，中台已经过气，微服务回归单体也一度成为技术圈讨论的热点话题，曾经神坛上云遮雾绕的 DDD 在今天看来是否还有讨论的意义？在过去一两年的实践中，笔者对 DDD 有了更深的体会，本文将阐述我的一些浅见，如果有理解不到位的地方，也希望同学们一起讨论。
一、领域驱动的理念
领域驱动这个概念一开始是由大神 Eric Evans 在2003发布他的名著《DomAIn Driven Design：Tackling the Complexity in the Heart of Software》中提出，从标题中可以直观的知道 DDD 是为了解决软件系统的复杂性问题，是一种降低业务系统复杂度的方法论，许多同学认为领域驱动难以理解，是因为他提出了很多抽象的概念，我们不妨先抛开这些概念，先去理解一下它去解决问题的思路。
1、统一语言与模型
对于一个开发来说，我们的工作一句话就是：用代码实现需求，在实现的过程中不同的人、不同的团队，可以有不同的实践，领域驱动就是其中的一种实现路径。领域驱动在需求到代码之间试图建立起一条桥梁，桥梁的名字叫统一语言和模型。

文章插图
什么是统一语言？软件开发的核心难度就在于处理隐藏在业务知识中的复杂度，想要处理这种复杂度，首先需要打破业务与技术之间沟通壁垒，在一个项目中，不光是有开发人员，还有测试、运维、产品、pm 等等，能把事做成的前提是可以把事情说清楚，我们知道中华文化博大精深一句话在不同的环境、场合下完全有不同的语意，统一语言的思想就是提倡团队内通过不断沟通去确定在一个业务领域中的术语或概念有唯一明确的语意。
那什么是模型呢？我总结为：一种化繁就简的抽象，抽象是目的是为了简化问题，先忽略细节，从顶层思考问题，抽象不在乎形式的表达，而取决于如何看待问题和分析问题的角度，我们举几个例子说明：
把大象装进冰箱需要几步？一共三步，打开冰箱->放入大象->关上冰箱。
虽然这是一个梗，但不得不说，这是很好的一种面向过程的抽象。

程序=数据结构+算法。

这已经变成了计算机科学中最基本的一条原则，即任何程序都可以分解为算法+数据结构，虽然程序要解决的问题都没有确定，但是已经有了一个思考问题的方向。

类图、流程图、架构图...

对于一个比较复杂的系统，我们很难通过几句话把它讲清楚，这个时候，画图就成为了一个好的表达方式，而画图就是一种抽象，根据你想抽象角度的不同使用不同类型的图。例如有人让你讲讲购物网站做了什么，你可以把问题简化并用下图表示，即描述用户、商家、平台之间的关系，这正是面向对象的建模思路，而领域驱动本质上也是一种面向对象的建模方法。

文章插图
在引入统一语言和模型抽象的思路之后，就可以把需求到实现的这个过程用下图表示，技术和业务的相关同学通过统一语言去沟通交流需求，通过模型抽象描述需求，最后按照模型去实现相应的代码，领域驱动的一大目标是：修改需求即修改统一语言，修改统一语言即修改模型，修改模型即修改代码，这也就实现了从需求到代码的有效信息传递。