DDD虽然诞生的早，但直到现在，和我们日常工作的距离也并不远，例如我们代码中经常出现的XxxEntity，XxxRepository ，XxxService，XxxFactory……这些类，这里的Entity、Repository、Service和Factory，以及我们现在大家早已习以为常的分层架构，都是出自DDD之手，只不过很多人已经不知道这些都是拜DDD所赐而已。

我们中的大多数人就像“猴子定律”里后来的猴子们一样，习惯了约定俗成，日复一日重复着（Controller-Service-Repository-Entity => CRUD）这些看似枯燥的操作，而早已忘了为什么一开始架构和这些所谓的最佳实践被设计成这个样子，少了一份溯本求源的精神。

以致于我经常在面试的时候，问候选人，你这里为什么要一个Service呀？大多数的回复都是：这是规范呀！这不是基本常识么？我们公司规定都得这么写的……

那说来说去，DDD到底是什么呢？

在我看来，DDD其实就是面向对象的一套“方言”，提供了一种基于业务领域的对象划分和分类方法，其最大的价值就在于对于软件开发过程全生命周期使用语言的统一！

怎么讲呢？

在面向对象的世界，只告诉了我们万事万物皆是对象。但并没有告诉我们对象究竟应该怎么组织，该以什么角度进行划分。

而作为技术人员的我们，早已习惯了从技术的角度出发思考，自然就出现了“用技术的语言”定义对象的习惯，例如最常见的DAO（Data Access Objects），DTO（Data Transfer Object）这类对象的划分方式就是使用技术视角看待和分类对象的典型案例。

这样从技术视角分类对象的问题，就在于在软件的开发过程中，会涉及到多“语言”间的对应和翻译，例如最常见的就是业务语言和技术语言的相互翻译。想想周围经常出现的研发和产品之间各种痛苦的沟（吵）通（架）场景，应该就知道我说的意思了。

这个过程其实和两种不同语言（例如中文和英文）的人之间的沟通是一样的，而且更加隐蔽，因为说的明明都是中文，但是彼此就是听不懂彼此说的到底是什么意思，而且都觉得对方像个傻子，听不懂人话，殊不知其实两个人说的本身就不是同一种语言。

而DDD的出现，就是为了解决这个问题。它通过一套面向对象的分类方法或是方言体系，从领域出发，实现软件开发过程中各个角色和环境的“统一语言”（UBIQUITOUS LANGUAGE）。例如使用“仓库（Repository）”替代“数据访问对象（DAO）”，就更能让业务和技术同时理解这个对象的作用。

就像车同轨，书同文一样。

好了，了解了DDD的来历和价值，那你肯定还有疑问，既然DDD这个概念已经快被人们淡忘了10多年了（虽然我们一直还在不知不觉中僵硬地应用着），那为什么最近一两年又突然重出江湖，重新被大家关注了呢？

答案其实就两个：微服务和中台。

说到这里还有个段子：

其实DDD一开始的时候，就把领域分析设计分为了战略（Domain、Bounded Context）和战术（Entity、VO、Repository、Service……）两个部分。按道理应该从战略入手，再下沉到战术部分。但是Eric Evans在写《Domain-Driven Design》这本书时，可能是基于当时的环境，却是先写的战术部分，书的后半部分才开始展开DDD的战略部分。

而又因为战术部分本身就很复杂很枯燥（各种图各种代码），所以很多人并没有坚持到读后边的战略部分，就读不下去（比如我）。导致的结果就是这么多年战术部分被大家充分的讨论和应用，而战略部分的影响则相较之下非常有限，讨论和应用的也不多。

直到微服务的横空出世……

随着微服务架构的兴起，微服务到底如何拆分就成了人们最最关注的问题。这时候一些“老人儿”们突然想起来，这不是正是应用DDD中战略部分（问题域，限界上下文）应用和施展拳脚的场合么？！

所以随着微服务的爆炸式发展，DDD这位退隐已久的老江湖，又再次被请出了山，站到了大家的面前。

而此时，他身边还多了一个年轻的新搭档，他正是：事件风暴。

EventStorming（事件风暴）

现在，当很多人谈到DDD都会同时谈到EventStorming，甚至有人误认为这两个名词本身指代的就是同一个概念。

但其实这是两个完全独立的工具。

DDD是一套基于领域的分析和建模方法，而EventStorming则是一套Workshop（可以理解成一个类似于头脑风暴的工作坊）方法。DDD出现要比EventStorming早了10多年，而EventStorming的设计虽然参考了DDD的部分内容，但是并不是只为了DDD而设计的，是一套独立的通过协作基于事件还原系统全貌，从而快速分析复杂业务领域，完成领域建模的方法。

EventStorming最初由Alberto Brandolini（曾受邀参加了DDD-China 2017）开发，经过DDD社区和ThoughtWorks的很多团队实践验证后，于2015年11月进入ThoughtWorks技术雷达，开始被更多人知晓和应用，从此成为DDD的最佳拍档。

关于EventStorming的具体内容和细节，已经有很多文章都介绍了，不过还是强烈建议先看一下eventstorming.com 官网的那本作者Alberto Brandolini自己写的《Introducing EventStorming》，应该是最官方最正宗的对于EventStorming的介绍。

而书中的下面这个图，我认为是对于EventStorming最清晰、完整且简单的概括。完整的阐释了从系统外部与用户的交互，到系统内（事件-策略-命令-聚合-事件）的事件传递涟漪，以及通过事件影响到读模型从而给予用户动作的响应，从而形成完整闭环的全过程。对我们了解还原系统的全貌非常有帮助。

前面提到了，EventStorming和DDD两个独立的工具，形式不同、解决的也是不同的问题，那为什么这两者总是搭档出现呢？

关键就在于下图这条红线，就像是月老手中的红线一样，将两个概念牵在了一起。

DDD提供了一套面向对象的“方言”，给出了一套面向对象的分类框架和架构指引，但是在DDD中并没有明确给出如何为一个系统识别出这些不同种类的对象的过程和方法。

而EventStorming的出现正好弥补了这个空白，通过EventStorming工作坊的方式，正好给我们提供了一个还原和分析系统的方法，并最终通过“聚合”这条红线，穿越时空，无缝切入到DDD的领域范畴之内，以“聚合”为支点，向上可以进一步做问题域和限界上下文的战略分析，向下则可以通过聚合的进一步展开进行实体、值对象等相关的战术分析，引导落地。

而DDD战略设计中问题域和限界上下文的识别，则为我们划分微服务提供了非常强有力的支撑，至此我们就通过EventStorming和DDD的这一对强力组合的联袂辅助下，找到了解决了微服务架构下最困难问题之一的，既服务该如何划分问题的解题思路和落地方法。

那说了半天微服务，DDD和EventStorming到底又与业务中台有什么关系呢？

本文转载自健荐公众号。

原文链接:https://mp.weixin.qq.com/s/H_KiY9sxTMAN4xrYwZOqRg

创作场景

白话中台番外篇：DDD、EventStorming 与业务中台（二）