DDD峰会归来话DDD

DDD是什么正如Alberto在keynote中提到DDD不是架构。我赞同这一观点并一直认为DDD是一种方法论Methodology。根据维基百科Methodology is the systematic, theoretical analysis of the methods applied to a field of studyDDD正是针对软件领域提供的系统与理论分析方法。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进行设计包括EventStormingEvent SourcingCQRS考虑event的不变性与消息的本质我们还可以将如下内容引入Functional ProgrammingReactive Programming那么我们是否可以提出Event Driven Design的设计概念呢与EDAEvent Driven Architecture不同EDD算是DDD的一种分支是一种设计方法学涵盖了战略设计与战术设计等多个层次。而它与传统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人员它其实基于两个前提业务是不可控的技术却相对可控相对于技术业务对变化更加敏感我们也无法正确地预测业务的变化技术的复杂性可以通过分工来解决多数应用开发公司可以重用微服务的平台、框架或工具然后集中精力来对付业务降低了业务复杂度就等同于降低了整个系统的复杂度DDD的未来