DDD峰会归来话DDD

一场大戏落幕，首届DDD中国峰会如大会主题色一般的红。或许在12月9日这一天，全中国的DDD粉丝大约有一半都汇聚在了国家会议中心。听起来是幸，其实是不幸，因为DDD在中国的人群基数实在是太少了。

因为要负责大会的其中一个Track，期间又要接受采访，另外还有朋友到访，所以除了前面的两个keynote以及我自己的session（这是当然的），我没有完整听完一个session。然而单单是和DDD大咖、专家与爱好者们交谈，已经受益匪浅了。参会归来，关于DDD的idea产生了许多，我觉得有必要和DDD谈谈我的想法。

正如Alberto在keynote中提到，DDD不是架构。我赞同这一观点，并一直认为DDD是一种方法论（Methodology）。根据维基百科：Methodology is the systematic, theoretical analysis of the methods applied to a field of study，DDD正是针对软件领域提供的系统与理论分析方法。Eric在创造性地提出DDD时，实则是针对当时项目中聚焦在Data（主要是DB Schema）为核心的系统建模方法的批判。这种面向数据的建模方式无法应对日渐复杂的业务逻辑，也无法更好地应用当时正沸沸扬扬的OO设计思想。这是设计观念的转变，蕴含了全新的设计思想、设计原则与设计过程。

坦白说，Eric Evans的DDD奠基之作《Domain-Driven Design》并没有非常清晰的系统脉络，战略设计与战术设计也未成体系。Eric创造了一堆新奇的概念，隐隐中确乎有一条围绕“领域”进行设计的思想主线，但对整个设计过程的描述却是不清晰的。结构上，我更认同Vaughn Vernon一书《Implementing Domain-Driven Design》，该书清晰地给出了从战略设计到战术设计的设计过程。

我在和ThoughtWorks的余丹妮聊到DDD时，我吐槽说Eric的DDD其实没有解决三个问题：

余丹妮则认为DDD不是架构（设计）方法，因此不能把每个设计细节具象化。DDD是一套体系，这就决定了它必须具有开放性，在这个体系中你可以用任何一种方法来解决这些问题。我深表赞成，却也认为这些关键问题如果没有具体落地的方法，可能会让团队无可适从。这其实也是DDD在许多项目中难以推行的部分原因。

Alberto是EventStorming的创始人，他在keynot中强调建模应该专注于event。EventStorming方法贯穿了DDD整个设计过程，包括Ubiquitous Language、Bounded Context等战略设计的元素，也能沉入战术设计中，以Event作为主要的设计驱动力。

在聆听Alberto的演讲时，我突然想到这种以领域事件作为设计驱动力的思想会否走出另一条不同的路（分支）。我之前在《或许是领域建模的真相》中模糊提到这样的思想，例如针对事件建模，实则是对业务流程以“状态机”形式进行建模。状态的迁移，就是command或者decision对event的触发。

如果我们再将event视为一种不可变、可追溯的消息，那么DDD社区提出的许多知识都可以围绕着event进行设计，包括：

考虑event的不变性与消息的本质，我们还可以将如下内容引入：

那么我们是否可以提出Event Driven Design的设计概念呢？与EDA（Event Driven Architecture）不同，EDD算是DDD的一种分支，是一种设计方法学，涵盖了战略设计与战术设计等多个层次。而它与传统DDD的区别在于建模思想与编程泛型的不同。

我说“微服务拯救了DDD”，其实是对肖然说的一句戏言，并不准确。在诸多社区力量的贡献中，DDD一直都在生长，在DDD提出来的十五个年头，不仅没有走入老年期的落寞，反而在每年都生长出不同的嫩绿新叶。既然DDD没有衰亡，何谈拯救？然而，不可否认的是因为微服务的火热，让DDD这种缓慢生长的态势突然焕发了勃勃的生机，就好像给这棵大树注入了生长剂一般，一下子开枝散叶。凡微服务所及之处，皆可见DDD的身影。这就造成了微服务拯救DDD的错觉。

我在演讲《Bounded Context的实践意义》中提及了六边形、限界上下文与微服务之间的关系，这里不再赘述。但肖然的《为不确定性架构》演讲提及了微服务保证了系统的simplicity，却让我浮想联翩。

对于架构，我一直强调对系统复杂性的应对。我曾经在十月份的一个会议上分享过《如何应对架构的高复杂度》，内容其实来源于我对复杂系统思考所撰写的一篇文章。我从理解力与预测能力两个角度剖析软件系统的复杂度。这个思考角度实际来自Jurgen Appelo对复杂系统理论的阐释。Jurgen Appelo将Complicated与Complex分别放在理解力与预测能力两个迥然不同的维度。Complicated与Simple（简单）相对，意指非常难以理解，而Complex则介于Ordered（有序的）与Chaotic（混沌的）之间，认为在某种程度上可以预测，但会有很多出乎意料的事情发生。如下图所示：

系统的规模与结构会干扰我们对系统的理解，而需求的变化则是我们无法预测的。那么，微服务是怎么应对系统复杂度的呢？核心思想是“分而治之”，它从系统规模着手，将一个大的系统拆分为一个个细粒度的服务。即使不考虑拆分的合理性，我们也可以看到它虽然控制了规模带来的复杂度，却加强了结构的复杂性。

个人认为，微服务对simplicity的保证，实则是将业务复杂度转移到了技术复杂度。显而易见，每个微服务的业务是非常简单的，代码易于理解和维护，也可以非常容易地进化乃至于替换。当我们需要开发和维护多个微服务时，如何管理和监控服务，如何梳理服务之间的通信，如何保证数据的一致性（最终一致性），都来自技术层面的挑战。

这种复杂度的转移为何能得到多数人的认同？针对IT人员，它其实基于两个前提：