DDD峰会归来话DDD

![](http://images2017.cnblogs.com/blog/526/201712/526-20171217215138780-484251651.png) 一场大戏落幕,首届DDD中国峰会如大会主题色一般的红。或许在12月9日这一天,全中国的DDD粉丝大约有一半都汇聚在了国家会议中心。听起来是幸,其实是不幸,因为DDD在中国的人群基数实在是太少了。 因为要负责大会的其中一个Track,期间又要接受采访,另外还有朋友到访,所以除了前面的两个keynote以及我自己的session(这是当然的),我没有完整听完一个session。然而单单是和DDD大咖、专家与爱好者们交谈,已经受益匪浅了。参会归来,关于DDD的idea产生了许多,我觉得有必要和DDD谈谈我的想法。 #### DDD是什么 ![](http://images2017.cnblogs.com/blog/526/201712/526-20171217215234796-1890122407.png) 正如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在许多项目中难以推行的部分原因。 #### EDD Alberto是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的错觉。 ![](http://images2017.cnblogs.com/blog/526/201712/526-20171217215348280-326537217.png) 我在演讲《Bounded Context的实践意义》中提及了六边形、限界上下文与微服务之间的关系,这里不再赘述。但肖然的《为不确定性架构》演讲提及了微服务保证了系统的simplicity,却让我浮想联翩。 对于架构,我一直强调对系统复杂性的应对。我曾经在十月份的一个会议上分享过《如何应对架构的高复杂度》,内容其实来源于我对复杂系统思考所撰写的一篇文章。我从理解力与预测能力两个角度剖析软件系统的复杂度。这个思考角度实际来自Jurgen Appelo对复杂系统理论的阐释。Jurgen Appelo将Complicated与Complex分别放在理解力与预测能力两个迥然不同的维度。Complicated与Simple(简单)相对,意指**非常难以理解**,而Complex则介于Ordered(有序的)与Chaotic(混沌的)之间,认为**在某种程度上可以预测,但会有很多出乎意料的事情发生**。如下图所示: ![](http://images2017.cnblogs.com/blog/526/201712/526-20171217214055796-572284245.png) 系统的规模与结构会干扰我们对系统的理解,而需求的变化则是我们无法预测的。那么,微服务是怎么应对系统复杂度的呢?核心思想是“分而治之”,它从系统规模着手,将一个大的系统拆分为一个个细粒度的服务。即使不考虑拆分的合理性,我们也可以看到它虽然控制了规模带来的复杂度,却加强了结构的复杂性。 个人认为,微服务对simplicity的保证,实则是将业务复杂度转移到了技术复杂度。显而易见,每个微服务的业务是非常简单的,代码易于理解和维护,也可以非常容易地进化乃至于替换。当我们需要开发和维护多个微服务时,如何管理和监控服务,如何梳理服务之间的通信,如何保证数据的一致性(最终一致性),都来自技术层面的挑战。 这种复杂度的转移为何能得到多数人的认同?针对IT人员,它其实基于两个前提: * 业务是不可控的,技术却相对可控:相对于技术,业务对变化更加敏感,我们也无法正确地预测业务的变化 * 技术的复杂性可以通过分工来解决:多数应用开发公司可以重用微服务的平台、框架或工具,然后集中精力来对付业务;降低了业务复杂度,就等同于降低了整个系统的复杂度 #### DDD的未来 在接受会议主办方的采访时,希望我能给DDD打call。那么DDD重要吗?非常重要,但它确实不是“银弹”。正如前面所述,DDD其实一直在生长。由于没有任何一家商业化公司推动DDD,它反而没有受到利益关系的干扰,虽然生长缓慢,但却健康。DDD以“领域”为核心,只要软件系统仍然还在处理“领域”,理论上DDD就有其生存的空间。如果我们不把DDD具象化(正如前面所说),它就可以成为一个不错的“框”,凡是和“领域”相关的理论、方法、实践与模式,都可以往这个框里塞。 倘若能一直**保持DDD的开放性,保持DDD的独立性**,我觉得在未来的五年乃至十年,DDD仍将焕发生命力,只是它的面貌会更加多姿多彩,甚至超过Eric Evans对DDD的原初定义。毕竟,软件系统的核心只有两个:领域和算法。也许,只有到了AI算法能把领域开发的职责都能揽过去,DDD才不会存在了,因为那时候已经没有了领域,只剩下了算法。
posted @ 2017-12-17 21:51 张逸 阅读(...) 评论(...) 编辑 收藏