一场大戏落幕，首届DDD中国峰会如大会主题色一般的红。或许在12月9日这一天，全中国的DDD粉丝大约有一半都汇聚在了国家会议中心。听起来是幸，其实是不幸，因为DDD在中国的人群基数实在是太少了。
因为要负责大会的其中一个Track，期间又要接受采访，另外还有朋友到访，所以除了前面的两个keynote以及我自己的session（这是当然的），我没有完整听完一个session。然而单单是和DDD大咖、专家与爱好者们交谈，已经受益匪浅了。参会归来，关于DDD的idea产生了许多，我觉得有必要和DDD谈谈我的想法。
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其实没有解决三个问题：
如何进行领域建模
如何识别Bounded Context
如何在战术层面寻找对象
余丹妮则认为DDD不是架构（设计）方法，因此不能把每个设计细节具象化。DDD是一套体系，这就决定了它必须具有开放性，在这个体系中你可以用任何一种方法来解决这些问题。我深表赞成，却也认为这些关键问题如果没有具体落地的方法，可能会让团队无可适从。这其实也是DDD在许多项目中难以推行的部分原因。
EDDAlberto是EventStorming的创始人，他在keynot中强调建模应该专注于event。EventStorming方法贯穿了DDD整个设计过程，包括Ubiquitous Language、Bounded Context等战略设计的元素，也能沉入战术设计中，以Event作为主要的设计驱动力。
在聆听Alberto的演讲时，我突然想到这种以领域事件作为设计驱动力的思想会否走出另一条不同的路（分支）。我之前在《或许是领域建模的真相》中模糊提到这样的思想，例如针对事件建模，实则是对业务流程以“状态机”形式进行建模。状态的迁移，就是command或者decision对event的触发。
如果我们再将event视为一种不可变、可追溯的消息，那么DDD社区提出的许多知识都可以围绕着event进行设计，包括：
EventStorming
Event Sourcing
CQRS
考虑event的不变性与消息的本质，我们还可以将如下内容引入：
Functional Programming
Reactive Programming
那么我们是否可以提出Event Driven Design的设计概念呢？与EDA（Event Driven Architecture）不同，EDD算是DDD的一种分支，是一种设计方法学，涵盖了战略设计与战术设计等多个层次。而它与传统DDD的区别在于建模思想与编程泛型的不同。
微服务拯救DDD我说“微服务拯救了DDD”，其实是对肖然说的一句戏言，并不准确。在诸多社区力量的贡献中，DDD一直都在生长，在DDD提出来的十五个年头，不仅没有走入老年期的落寞，反而在每年都生长出不同的嫩绿新叶。既然DDD没有衰亡，何谈拯救？然而，不可否认的是因为微服务的火热，让DDD这种缓慢生长的态势突然焕发了勃勃的生机，就好像给这棵大树注入了生长剂一般，一下子开枝散叶。凡微服务所及之处，皆可见DDD的身影。这就造成了微服务拯救DDD的错觉。
我在演讲《Bounded Context的实践意义》中提及了六边形、限界上下文与微服务之间的关系，这里不再赘述。但肖然的《为不确定性架构》演讲提及了微服务保证了系统的simplicity，却让我浮想联翩。