DDD分享笔记

灰太狼 2022-09-01 09:23 181阅读 0赞

我介绍啊啊所谓的这个近期的这些分享呢，基本都是在这个一年以内。就是这一年以内呢，其实参与了这个多个平台的这个呃讲座。和这个分享的这个活动啊，包括比如说这个呃examine啊，包括这个他不让hurry的啊，包括q com plus。

就是还包括公司内部的技术沙龙。就是因为分享的这个比较的密集啊，同时呢我对自己也有一定的要求，就是每次分享的内容是不能够和以前重复的。所以呢就是等于是啊做了一个比较细袅化的这么一个分享，把这个自己对DDD理解的这种各个方面。

然后都做了一些阐述。今天呢就是分享的这个内容呢，大概百分之七八十，其实也是在之前。并没有这个跟大家说过的啊。可以说是这个自己最近一个月当中经过一些思考，然后呃怎么说呢？得到了一些思考的一些成果的进展吧就是。

怎么说呢？就是。我感觉就是说对这个DDD这个事情确实是比较的博大精深啊就是。自己呢就是会面临一些问题，别人也会问我一些问题。然后我针对这些问题会有一些思考。然后呢就是到了这个阶段来讲呢，是有一些进展和进步。

但这个可能并不是一些结论性的一些东西。今天正好咱们这个节目叫做技术损坏。所以说呢嗯就和大家这个聊一聊啊，自己最近对于记忆力的一些。新的看法，新的思考。啊，接下来呢就是会很快的用3张PPT啊，简单的介绍一下什么是DDD。

然后呢，就是我担心就是今天来听节目的同时，有一些其实对于滴滴的了解啊，或者是是听过这个名词啊，但是了解的还。所以说今天就是简单的，我用3张PPT。来给大家讲一讲，就是怎么说呢？啊，滴滴滴的一些宗旨。什么是DDD呢？就是3张PPT肯定无法讲解这个滴滴滴的全部啊。

没有办法给大家讲DDD的全包是什么样子的，但是呢可以把DD的精神给大家就是展示一下啊，第一个就是追求一致。追求业务组织和这种技术架构的一致。追求抽象的这种领域的这种划分和具体的先进。查找文微服务划分的一致。

追求这种领域模型和微服务设计的一致。追求这个共同语言与需求语言和代码的一致。再有一个就是。模型驱动。就是领域模型是系统设计的抽象，因为模型同时是产品模型的出现。再有一个就是很重要的一点就是基于这个UBCOTS language啊，就是基于共同语言。

就是领域内产业对共同语言有共同的理解，共同语言体验。在需求设计及产品代码的实践当中。就我认为啊就是说从我的总结上来看的话，就是呃如果是基于这三种的一种我们的一种呃一种技术实践工作，或者是其他的一种工作的话。

那么他都可以理解为是一种DDD的这个体系下的一类工作。好，第二张PPT呢给大家讲是DDD的地图。就是DDD我一般来说它就是一个快是一个非常具有扩张性的这么一个扩张性理念的。啊，这么一个技术体系。就是大家可以看到啊，就是从最开始的这个方法及工具啊，这些方面的话可能是一些呃产品领域的，或者说是管理领域的。

的一些事情。然后到第二第二部分大家可以看到有一些领域建模的一些工具啊，包括战略设计战术设计的一些工具啊，然后还有我们的一些。三个还是我们刚刚最喜欢的一种啊，我们的这种整体架构设计，微服务架构设计以及微服务的分层架构设计。

能够能够知道的最耳熟能详的一些各种各样的模型是四层结构，什么六边形结构，什么这种洋葱模型，然后是整洁架构模型。这些怎么说都是在这个微服务设计这一趴里面。还有就是说是我们的一些具体的一些框架的实现，以及代码的基于这个微服务设计的一些代码的一些实现啊，以及这个我们的API设计。

以及我们的这个啊测试以及持续集成啊这一部分来看来说是和我们的这种的基础设施又息息相关。所以大家可以看到啊，其实DDD它是一个。这个软件研发的各个。领域的点，然后都集合起来有点极限青春面的这么一个非常具有这种非常非常这种。

历史。又去想了这么一个。技术体系。就我都不可以说它是一个呃设计模型或者是一个框架啊，其实它和这个TDD和什么BDD来讲的话是完全不能相比的。就是弟弟弟来讲的话，他是一个扩张性的，而且还在不断扩张的这么一个。

技术体系。其实DDD的这个核心啊，我们可以理解为是从这个呃领域建模开始的啊，就领域模型驱动嘛，对吧？从这个error key events的那本书里。他最开始讲的就是什么是领域模型啊，什么是领域模型驱动啊，这个是它的最开始的一个核心。

但是呢从现在开始呢，就是说他越来越向前，也越来越向后。也就是说，越来越考虑这种他和这种这种这种软件实现的愿景的这种关系啊，以及实现这种远见的愿景，实现这种愿景分析的这种工具。啊，这节课的东西开开始大家开开始研究以及分析，以及来实现这种去实现DDD的一种时机来进行这种分析。

再有就是在逐步的往后啊向后啊，就是说我们会去做一些工具啊，来去帮助我们的领域模型如何更好的落地啊，形成我们的。但是在我们形成我们的这种代码，形成我们的这种上下文的这种映射关系和我们的这种真实的这种比如说RPCHTBI这种交互关系的时候，他是否是这种。

正确的这种对应着啊，我们过去实现很多的这种工具来帮助我们去完成这种对应的关系。这个也是我们一个向后的一个非常重要的一些一些目前的一些思考和我们产生的一些工具啊就是。另外呢，其实在这个我这次的分享当中啊，还会说到一些向上的一些向下的一些思想。啊，其实来讲的话，他是他不仅仅有这个向前和向后两部分。

其实还是还在向其他的方向进行扩展啊，在本次分享当中的话，我会逐一给大家做一个介绍。再有就是第三趴，第三趴就是前两趴的话，其实我是在尽力，就是怎么说呢？在和大家讲DDD又是炸鸡的宗旨是什么？弟弟有什么？然后呃怎么说呢？最后再说给大家介绍几本书。

最推荐的这本书就是我右边这张图上这本书叫做领域驱动设计精粹。就是这本书的话，其实是说是怎么讲呢？是他比较文字非常少，大概是7万多字啊，就是大概是花啊四个多小时的话就能够阅读一遍。其实他等于是说这个word worlder的话，他等于是说为这些初学者初次怎么说呢？就是初次这个理解DDD的这个用这个怎么说呢？

这些工程师们啊来准备的这么一本书啊，就是说你可以通过很少的时间，然后通过呃4个多小时的时间把这个7万多字的书读完之后。你就可以入门DDD来进行这种怎么说呢？DDD的一些啊尝试。另外再再介绍的要求是，这个第四本书就是在这里面的中台架构实现啊基于DDD和微服务接口。这个我认为是国内里面就是说这个欧双喜老师这本书是国内的书里面做的非常好的一。

啊，就是说。他其实里面的话就是把我们非常流行的微服务中台和这个DDD。然后这这这几件事情做的一个有机的一个结合。并且呢他和这个。他和这个自荐比较流行这种微前端的这种思潮，也进行了一个他在他的这种理解下的框架理解下的这么一个解读啊。

就是怎么说呢？啊，当然也有一些很多的思想认为这个中台其实和这个DDD其实是没有什么关系的。其实来讲还是属于这个关系。是硬扭怪的啊，这个其实我在很多文章中也看。看到了这种这种看法啊，但是我我自己呢也会从这个我自己的理解当中来看。大家来讲的话就是来对这个中台微服务和这个DDD之间的关系来做一个。

解读啊，就是说我认为就是说认为就是怎么说呢，就是把这个中台和这个地址看的是没有关系的人，其实他也是有道理的啊，甚至于说部分正确。但是呢我仍然也找出来了，就是中台和这个DDT之间的一些关系啊，大家可以批判的。哎，这个听我说一下啊。

今天呢大概给大家分享这个5件事儿。现在咱们来说第一件事啊，就是从从0到高速公路，从敏捷到DDD。这个话题是怎么来的呢？就是从某某一次分享结束之后的话，就是有一个这个工程师朋友，然后就问我一个问题，就是他现在做的一颗一。

业务啊这个业务它是一个公司内相对而言偏边缘啊这么一个业务。但是呢这又是他是个团队里面非常核心的一块事儿。但是呢问题就在于既没产品也没技术啊，就是人员比较稀缺啊，在这种情况下能不能做这个DDD。这个从我的观点上来看的话，就这种情况来讲的话，实际上还是不能够这个。

做这种DDD的这种尝试，或者不适合来做这个DDT类型的这个尝试的。这个明显来看的话，就是它不属于一个呃怎么说呢？一个核心业务，或者是不会在这个这个方面上怎么说做这个过多的一个投入。这个从这个这个从这个角度上面来看的话，如果去做这种啊DDD类型的这种重构类型尝试的话，就是怎么讲呢？

很可能是达不到目的的。但是呢当时呢，就是他又问了价格问题，那我在什么情况下，我可以开始进行这个DBD的尝试。就是。嗯，怎么讲呢？就是这个这个问题的话呢，怎么讲呢？其实呃就引起了我自己的一个思考啊，就是说其实我觉得我第一个问题回答的也不是很好，就是怎么说呢？就是人家。

他是人家的一个核心业务啊，但是没有资源。但是在这种情况下的话，为什么就是就是不适合做这种啊滴滴滴类型的尝试，这个节点到底在哪儿啊？其实书上的话并没有说明这个问题。我自己呢后来再去通过一种思考之后，就今天把自己的想法分享给大家哈。就是说呃这个这个来讲的话，是我在这个北大这个听这个张一池老师的这个课的时候，然后。

哦，怎么说呢？我把这当然听张宇轩老师课时的一个更早时期的一个事情。但是我把这两件事情联系在了一起。张玉石老师是教这个人力资源管理的啊，就是他其实来讲的话，他讲就是说这个这个一个公司的业务其实有两种状态，一种叫做层连状态，一种叫做这种。

高速公路状态。从这个状态的话就是说呃怎么说呢？你可以朝着各个方向去走啊，去探寻啊，但是呢怎么说呢？很大程度上。你距离目标其实是不会越来越接近的。这种高速公路状态呢，就是说你可能还是有很多条路可以到达终点啊。

但是终点是确定的。啊，就是路径也是确定的。你走，你无论怎么走，都是在朝着这个路径在走，关键在于达到终点的这个效率如何。关于另一种说法来讲的话，就是叫做用这种咱们技术人来讲比较常见的说法叫跨越鸿沟。就是说可能来讲的话，在前两个阶段都是属于这种尝试阶段。

然后跨越了红宫之后，就进入了到了一个高速发展的这么一个阶段。也就是说你的目标比较明确的这么一个阶段。各种方面都要偏向去去向成熟的这么一个阶段，开始拼效率的这么一个阶段。就是那样来讲的话，其实这个用到这个DVD里面吧，就是说。

当你的这个业务虽然是核心，但是说当你没有一个怎么说呢？当你没有一个呃怎么说呢？一个很。很明确的一个一个目标，很明确的一个愿景，或者说很明确的支撑你这个一个这个业务生存下来的一个逻辑的时候啊。其实在这个阶段来讲的话，他也需要这种产研，就是在一起来这种通力的合作。啊，当然这种状态来讲的话，通常不适合这种做这种DDD类型的。

这么一种尝试啊，可能更适合作为1个DDD的一个前状态。啊，我们叫做这种这种敏捷开敏捷开发这种模式啊。可能这种模式来讲的话，更适合这种丛林状态。就是在我在这个007中税经费这本书里面来讲的话，也提到了就是领域开发其实是DDD的一个呃，怎么说呢？一个。

一个基础。啊，就是说它是一种产权合作的这么一种基础啊，但是呢。从我的看法来讲，讲的观点来看的话，就是敏捷开发所达到的这种目的和这种PPT所达到的目的还是截然不同的。啊。每节开发的话其实。更加的就是像我这张PPT里面所说的，其实更加的倾向于一种交付，更看重这种交付。啊，但是说这种从滴滴滴的角度上面来看的话，其实来讲。

而更加的侧侧重于这种怎么讲呢？侧重于这种过程，对于结果的这种影响。侧重于对于这种每一个过程啊是否一致性的这种要求。啊，这两种就是这种截然不同的。虽然他们从形式上面来看的话，都是一种产业通力合作的这么一种状态。

要是达到了目标的话，是完全不一样的。所以来讲呢，就是说当我们处于一种丛林状态的时。我们会去分析一下自己的业务啊，无论是这个产品还是研发啊，就是你到底有没有一个明确的愿景啊，到底是对于这个或者说对于这个接下来这个业务有没有一个明确的一个规划。

就是说如果说比如说这个这个答案是一个确定的的话，那么来讲他可能已经进入到了一个快用的这么一个阶段了啊。开始从这个从这个阶段进入到一个高速公路的这么一个。情况下啊，那没有，他是可以做这种开始做这种DDD的这种尝试啊。

就同时来讲呢，反过来说另一个事情就是说比如当你的这个这个业务，从这个丛林状态来讲的话，已经找到了一个相对明确出路来讲话的这种情况下。在继续这种敏捷开发这种状态其实也是不合适的啊，就是敏捷开发来讲的话，其实从这个从最终的情况上面来看的话，其实它并不是一个。

资源很节约的这么一种这么这这么这么一种开发模式。就是呢来来来来讲的话，怎么讲呢？就是你如果说一直把这个高速公路也当做这种丛林来去看待的话，那么最终来讲的话就是产品会challenge你的这个交付的这种效率。

会不高啊？就是所以说呢，就是在这种情况下的话，就是当这种已经从这种。丛林当中结构阶段已经能够看到一个看到比较明确的愿景情况下的话，那么来讲的话，这种情况下是可以开始这种啊。地铁地铁下的这种啊，顿时这种构建或者是重构啊都是可以的。

嗯，举个例子来说的话，就是呃就是怎么说呢？就是今年来讲的话，其实呃去哪儿也做了很多这种非常成功的。这种。DDD类的这种重构类的一些项目。就是这个来讲啊，这是一个会员卡相关的一个项目啊，这个也是这个怎么说呢？就是在这个吴创新老师序里面提到的这么一类业务啊。

这个可能是咱们这个这个怎么说呢？技术所发的这个毛病啊，打卡可能对这个业务也非常熟悉。就是这类业务的话是怎么说呢？就是。我们其实来讲是在这个这个业务，这个产品和研发共同接手半年之后，然后才开始来做的这个真正的重构。啊，一方面就是刚才所说的，其实产品它需要摸索。

他需要这个怎么说呢？在这个从电状态下去找到这个东西，它真正的一个怎么说呢？真正的真正的一个目标，真正的一个愿景啊，真正的一个内在的可以长期影响的逻辑是什么啊？另外从这个技术角度上面来看的话，其实他也需要对这个移动系统做一定的了解。啊，这个左下角这张图的话，其实它的意义就在于这个他对于这个遗留系统的一个认知和这个了解的。

一个过程啊，然后这个左上角和这个右边的话，其实是他这个对遗留系统的这个了解之后啊，在这个对这个系统还只有这个半年左右的这个了解之后，然后做的一些输出。这些是没有经过这个怎么说呢？其实事件分包啊，因为这些事情然后直接做出来的一些输出，就他和这个世界通道这些事件就是所谓的DDD体现的一些事情做出来的输出来讲其实是。

还是有一定的这个差别的啊，但是很想画。他能够把一个遗留系统来讲的话，这个怎么说呢？也大致是一个什么样子，然后他能够做一个呃比较好的梳理啊，甚至于说的话。在这个在这个阶段来讲的话，他能够对这个小做一些微重构啊，也就是说对他做一些简单的一些这种分层处理。大家可以看到这样能够为以后的这种。

在这种DDD体系下的一些啊做的做的一些真正的这个比如说我们要做一些这个微服务与这个领域模型的这种啊这种抽象模型抽象的这种领域划分和这种具体的这种微服划分一致的话。要做在做这种事情时候会显得比较容易。这个是比如说就是像我们在做这个会员卡项目的时候啊，就是当我们做完这个。

怎么说呢？就是这个当这个产品有了一些方向。当我们这个啊做了一些移动系统的处理之后的话，那么我们开始用这种比较这种正确的这种这种这种实践风暴这种方式。来去这个做这种真正的这种滴滴滴方面的这种重构。

这个来讲的话是我们的这个另一个案例。就是这个案例的话，其实呃说明的还是一个类似的问题啊，这个是我们在这个呃某个业务的这个售后里。啊，然后做的这么一次地地地图或者这么一个尝试啊。就是这个案例的一个特点是什么呢？就是说大家可以看到他在事件公告的时候，其实。

已经就是怎么说呢？就是做出来的是这样一个就是这这样一个分布啊。但是来讲的话，他在这个做这个事件风暴之前的话，其实他大概准备租用两个月的时间。一个是来讲的话，就是他的这个呃参与这个重构的工程师要去了解这个DDT方面的一些知识。啊，另外来讲的话，就是他的一些这种产品人员的话。

他也会就是怎么说呢，啊，来去不停的这个来去这个咨询。就是说这一块他这个领域里面到底适不适合做这种滴滴代理性重构这个资源的这个投入。是否值得？其实来讲，他也是在问他自己，就是说这个来讲他自己的这个究竟有没有一个明确的一个目标啊，就是做完之后要达到一个什么样的一个目。

再有呢，其实就是说在这两个月里面的话，其实呃在准备了两个月，然后就是去哪进行了，怎么讲。对于这个一些技术下沉类的工作，在后面也会提到啊就是说。我们做了一些这种滴滴的课程和培训啊，一共是这个10次左右的课程。中间还有一次这个去哪儿技术沙龙，就是把这个。

一些啊怎么说呢？公司以外的一些朋友，然后这个邀请过来，然后做了一次这个呃怎么说呢？对外的一次滴滴滴的一次分享。但是总共来讲，它就是这个课程大概是十四课程啊。在这个过程当中的话，其实在公司内部的话也培养了一批对滴滴滴有了解感兴趣。并且这。

啊，怎么说呢？认为这个滴滴滴的这个这种重构啊，这种这种业务重塑是对自身的这种这种业务是一种有帮助，是想要怎么一些更有认同感的分配。显示。这个这个案例来讲的话，大家可以可以看一下啊，就是说最开始啊是要做这种事件风暴。然后的话在这个事件风暴完了之后，要做一些命令。风暴。

命令风暴的话其实是就类似于这个我们平常这个产品或者加班画一些流程图。但是他要比流程图的话，显示有点像看起来啊更全面和具体。然后命令风暴完了之后的话，然后我们会做这个微服务和这种啊微微服务映射的这个连接。

啊，就是这个这个contains making的工作。然后再再往后呢，我们会做这个我们的这个领域划分啊，去划分这个核心领域，支撑领域和这个抽中领域。然后我们会针对核心领域的业务，然后会做这种这种领域模型的设计。

然后在里面模型设计之后的话，然后我们会做这个呃微服务设计以及这个微服务内的分层设计啊，直至这个代码实现。啊，右边是我们这个。这个怎么说呢？基于这个coco4.0的这个代码实现。大家可以这个怎么说呢？把这个流程的话记一下啊，为什么呢？其实我后面还会讲一个案例，其实它的这个流程和这个是完全一模一样的。

我认为这个和我们的这个就是这个滴滴的这个培训，其实是有一定的关系的。在滴滴培训当中的第四讲和第五讲里面，其实来讲我们都做了这种挂盘的讲解。就是这个就是这个实践的流程和我们挂盘讲解的流程是这个完全一样的。

所以来讲的话，就是从那以后的话，就是所有的这种这种怎么说，就这种DDD的这种领驱动设计，所有的流程就都是一种相对比较统一的这么一种流程设计。然后第二个要讲的就是这种。滴滴的普及标准化到高效化的这么一个过程啊。

就是呃为什么呢？就是这种最开始的话就是实现这个DDD来讲的话，还是会有一定的这种啊效率问题啊，就是说我们这个怎么说呢？就是这个事件风暴的时间会比较长，然后这个。呃，怎么说呢？每一次讨论可能得到的这种结果，相对而言的话怎么讲呢？呃，结果不大啊，就是说我们会做这种多次的这种尝试，然后达到一个。

阶段性的一个目标。那么其实我们要做的就是把这个这个把这个就是这种像这种世界公报这种流程做一个标准化的这么一个工作。啊。然后呢接下来呢就是说当我们把这个流程标准化了之后的话。那么我们就可以逐步的去高效化制成这个流程。

首先让我们得说一下，做的是一种技术下沉类的这种工作。就是我们这个技术下沉的话，其实呃怎么说呢？一方面的话是我们内部啊我们在在内部然后做的这个地铁地铁零驱动课程。啊，这个课程不仅有我这个内部的一些这个。观众有我们这个外部的这个也吸引了很多这种外部的这个怎么说呢？就是小伙伴他一起来这个我们的群里面来做这个参与。再有呢就是说。

啊，怎么说呢？呃，也要有赖于这个类似于像我们技术所患啊，类似像我们这种QQQQ plus accept就是这种会议啊。这种会议里面的话，他会把第一题单单独的作为一个。咱的单独的怎么说呢？作为一个专题啊，还单还做这个宣传品的这个专题，他的这个号召力啊还是很强的啊，这些来讲的话都会使我们这个。

啊，怎么说呢？内部小伙伴会认为就是GDP它是一个怎么说，它是一个值得去追求的这么一个一种技术体系。啊，这是我们自己的一个滴滴这种驱动的课程。啊，咱们再有就是说我们要举的就是下一个例子啊，这个例子呢是我们一条业务线的一个呃也是一类业务啊。

就是大家可以看一下啊，就是这一类这类这类业务啊，其实这个这个这类业务怎么说呢？它在我们这种TC里面的话，一共评审了两次啊，第一次是在这个完全没有这种。作为这做这个TTD领域驱动设计的情况下，他自己做出一个设计。好，第二次是在这种有这种滴滴滴的驱动设计情况下，自己做的一个设计啊，这两者就是这两次的话我们可以拿出来来做一次比较。

这个是在这个他的这个第一次的一个设计。这个时候大家可以看到它有没有这个用例图啊，有这个流程图。就是你可以发现来讲，就是说这样的话就是怎么怎么说呢？就是我们在这种钉钉里面的，比如说像事件风暴啊什么的，可能它起到了作用，可能和这个用户意图其实是差不多的。所以。

拨打。但是呢。通过这个用力图最终得到这个怎么说呢？得到得到这个呃合适的这种。系统架构这个从这个层次上他有自己的一个内在逻辑啊，但是当我们没有经过这个滴滴滴的体系之后呢，从这个有用，从这种用力设计图直接到这种流程图。这种这种情况下呢。

就是我们会发现缺少一些设计感。就是说你会你会去想，就是说啊这个用力，然后用下面的这种流程去实现啊，就是说一方面也并也并不能看到这种这种他这种系统交互的一个全貌啊。系统层次的一个全貌。每层到底付出了什么样的事情啊？另一方面其实说真的，你也缺少一个标准去衡量，就是说他这么设计到底对不对？这么交互到底是对不对？

就是说怎么说呢？因为你并不知道，比如说交互的方式，比如说比如说REC交互是一个交互，还有这种纯异步的这种。比如说这种消息队列的这种交互啊，哪种交互其实是正确的。其实也你也得不到一个对应的一个标准啊，其实来讲的话，你自己也会也会也会对此产生一种疑惑啊。

但是这个呢这个来讲呢，就是说我们是一种就是一个相对而言比较标准的一个一个就是来做这种滴滴领驱动设计的这么一个流程。这个我觉得这个图其实是1个BR的一个它的一个这个渠道设计的一个一个流程啊，这个当然了，这种流程不是唯一的啊。但是呢你只要有了这个流程之后的话，你就可以让你的这个。

所有的这个滴滴领取到设计的这种项目，都按照这个流程来去执行啊。当你有了这种基础之后的话，有了这个基准之后的话，所有流程都按照这个这个流程去执行的话。那么它的效率。就会就有逐步提高的可能。并且事实上的话也真就会逐步的去提高。

对，大家可以可以看到这个项目其实一样的啊，还是这种对模型设计，然后面临风暴啊，然后这种。怎么说呢？就是这样这种这个这种上下文的设计，上下文映射啊，还有这个啊自定义域划分。你想上的这个领域模型就这个样子。

大家可以看到就是说其实来讲他是他等于是说是按照一定的这种的内在的这个逻辑去一步一步完成了这个设计。啊，我们可以认为这个领领这个怎么说呢？这个世界风暴。相当于这个最终的结果也相应当于这个是这个用力设计的这个结果啊可能差的并不多啊。但是来讲的话，我们他就没有了这个后面的这些。

这些一步一步跟上来的这个流程。当没有这些流程之后的话，那么来讲的话就怎么说呢？那个得到了一个结果，它其实就是一个资费不连续的。得到的一个结果啊，就是他的这个正确性，或者说这种逻辑的严谨，请求没有办法得到保证。

但是呢大家可以看到啊，像这种严格按照这种啊领驱动设计的这个流程。然后来做出来的这个呃模型和它的这个结果来看吧，一个是说。大家的所执行的过程几乎都是一致的啊，再有就是说大家所得到的这个结果啊，就是说怎么说呢？只要只要你认同这个这个领域设计的这个结果啊，最终他的这种。

呃，怎么说呢？这种先进商家和微服务的这种设计的这种这种结果与它是合相比是合理的。啊，那么有几条走错道，这个我在这个怎么说呢？这个PPT开头所说到的这个一致性。这一点啊，那么来讲你可能你很可能就是基于一致性的原则，认为它就是一个非常合理的一种设计。

这个就是说是一种有比较有依据的这么一种考察这个设计是否合理的这么一个标准。再有呢就是说呃像这种地地雷岛，它有一个怎么说呢？大家都看到这个比较属于这个四层模型的这种设计啊，就是说每一层的话它这个产生什么样的意义。

其实也是这个非常明确的。

但是呢就是说要补充一点啊，就是说嗯我们在这种啊，再比如说。这种这种这种这种使用，这种契合这种啊这种怎么说呢？整洁分层架构的这种这种比如说类似于这种啊寇纳架构的时候，其实我们还是要有自己的一个落地规范。

就是说从这种从领域模型到落地啊之间，其实还是需要有这么一套规范的。甚至于说是两套规范啊，一套是框架规范，一套是落地的代码规范。啊，我在这里只切出了一个框架规范，实际上还是应该有一套代码规范在的。这样两套规范在的话来约束的话，才能够保证这个我们的这种框架实践和代码实践与我们的领域驱动设计实践是这个一致的。

然后接下来讲的是这种前面两两个地方怎么说呢？就是。啊，一方面是讲了我们的一些在这个2021年的一些领域驱动设计的一些实践。其实我们的一些在实践过后的话，我自己的一些想法。再有呢就是我们在接下来讲的几个话题呢，其实是在想这种地理地啊，对于这个。

我们的这种领青世界周边的一些潜移默化的一些影响。这个怎么说呢？就是因为最近工作也比较忙，所以这个PPT呢后面几个就写的就相对而言就没有这么多图了啊。就是但是呢就是该说的地方呢，我也会。我们都会说。再有呢就是第一点就是说从基础设施的固定到基础设施的标准化啊，其实呢啊在在这个这个。

于姐开始时我提到了，就是说呃DDD的这种落地。其实是特别依赖于基础设施的完善了。无论是这个API的标准化啊，这种这种怎么说呢？这种我重构方面的这种啊自测的这种工具也。以及这种持续集成的这种工具啊，其实都是有赖于这个基础设施的这种这种怎么越做越厚的啊。再包括比如说我们在第一节设计当中的话，我们会有这种现阶上下文的这种各种的这种。

这种这种交互的这种方式啊，无论是这种这种RPC的交互，HTTP的交互。然后我们这种消费队列这种交互。这些交互企业来讲的话，他都应该是有一些对应的基础设施，然后来提供出来，来去标准化，来做这个支撑的。DDD能带来什么呢？能带来一种边界啊，就是能够他能够知道哪些是属于自己这种领域层的，哪些是属于基础设施层的。

啊，那么来讲做基础设施层的这些工程师们和咱们说，他们就能够和这个团队他们就能够去知道哪些是完全属于他们的这个领域。他们就能够去不断的去推进这些基础设施的不断的强化。就是呃怎么说呢？在这种一段时间之内的话，其实基础是和这个业务之间他们对于这种嗯基础组建的开发的边界其实是是。

相对而言是不明确的啊就是。但是呢就是说从这种滴滴滴的之后来讲的话，就是有了这种基础设施层的这种概念。或者比如说在就是说他自己认为，比如说叫做叫做platform s service，叫PNAS草啊。管这种业务层角度的SAS啊，就是source，就是那个就是什么什么soft risk service啊，就按照这样这样来来来来来来来讲的话，这么两层之后的话。

那么来讲，他们就不仅仅会是觉得自己是一个呃基础组建的这么一个提供方。那同时来讲的话。他会这种当他的这种技术组件的这种使用，相对而言比较的固定。相对而言，比较标准的时候，在这种基础组架，这种使用也会被变得标准化。

啊，这个是这个接下来的话就是怎么说呢？这个呃基础研发团队要去做的一些事情啊，就是他的这种使用都会变得这种标准化的。就是我在这里举的这个这这这几个例子来讲的话，其实来讲只是一种只是做的他们要做的其中的一部分啊，但是其实来讲的话。

怎么说呢？这种大家可以就是怎么说呢？就是从感受这么这么一种我要说的这么一个意思就是说。DDD其实会使这种基础设施操，他们会有意愿变得做的越来越厚实。他们会会会会做的会怎么说呢？把一些属于基础的东西，越基础的东西做得越来越标准。

这个是他们会。啊，怎么说呢？在这种滴滴滴的这种框架下，他们会去完成一些事情。再有一个就是从分层架构。分层架构。这个要设置什么事情呢？第一个分层架构说的是这个前面这一章的这个分层架构啊，这个是我们在微服务划分之后啊。

我们怎么说呢？在这个微服务内部做的这个分层架构啊，这个分层架构我们都非常的耳熟能详啊，大家都对它非常的熟悉啊。但是我说的第二个这个分层架构是什么呢？它是我们的一个整体性的这么一个分层架构的形成。就是DDD呢，它还是刚才那个观点，它产生了一种怎么说呢？它会让大家就是都会有一种边界的这么一种意识啊就是。

这种边界意识呢在这种呃软件设计方面的话，可能是个好的意识啊，就是我们会我们应该这么这么讲这件事情。就是说我们在做在做这种软件设计的，就是在和这个自己的兄弟团队进行沟通的时候有变化。文件意识确实是一个好的事情啊，但是作为一个人来讲的话，从一个人承担责任角度来讲的话，怎么说呢？就是可能这个边界意识并不是一个真正好好的一个东西啊，但是。

我们从这个软件设计上来看的话，有一定的边界意识，其实是能够促进这个怎么说呢？这个软件工程然后向着更为整洁的方向来发展。现在来看的话，就是我们的这种因为有了这些边界的意识啊，就是我们的这个整体的这个软件的结构啊，其实是向着这种。

层次越来越清晰的这种模式啊，就像这个右下角这个图一样，见到这个层次越来越清晰的这个方向。然后来做这种眼睛。就是。大家可以理解怎么说，我说这个开始说会有一个中台啊，就是中台是什么呢？其实。呃，中台如果不是从这种其他的视角上面来看的话，其实没有办法说自己是不是一个状态啊。这个我在一个其他的这个。

一个这个怎么说呢？其他的一个分享里面也讲过这个这个观点啊，就是但是呢比如我从前业务前台的这种BFF层的这个观点上面来看的话。那么来讲的话，为BIF层提供非常核心的这种业务能力的这些服务，我就可以把它看作是我的中台。

其实怎么讲呢？我们可以想到就是说其实定义地所服务的核心就是这几个六边形的这这这几层啊。这个是DDT所所核心所服务的这一基层啊，上面在此上此下此用啊，这些都不是DDD所核心的服务的这个核心层次啊。虽然这个鸥创新老师。

在他的书里面，其实提到了这个对于这个什么BFF层或者说BF层以上层，对于这种微前端这一块的一个支撑啊。提到这个比如说像这种呃像像这种领域驱动，其实它是一个领域的一个拆分。但是到了这种呃对于这种微服务层的话，其实它是一个领域的聚合。

其实讲到了这么一个观点。啊，但是来讲的话，呃，讲到这些的书还是非常少。另外一样的话，其实他其他任何我创新老师的这个这个观点其实不见得一致。另外就是说呃怎么说呢？就是不是每一个每一本。讲第一页书都会讲到类似的观点。

就是。这样啊就是。最核心服务的就是这个六边形所在的这个层啊，无论你是一个核心领域支撑率还是通用率，核心服务的是这阶层。但是呢就是说当你的当你的这个怎么说呢？这个服务越来越有边界感的时候，那么每一个服务针对于像BF层这种层的话。

就很可能他会把你看作是一个中台。而你自己之间的话，这些六边形之间的这个交互，他们是属于这种现阶上下文之间的这个交互。今年上下文之内的话，它的实体就是一个微服务。就是微服务陷进上下文和中台，其实只是从不同角度去描述一个事物啊。

在我看来可能描述都是这同一个实体啊，只是我我们可能再从这种再从这种比如说抽象的这种这种领域模型和这种实际的这种这种现阶上下文关系的一致性方面的时候，我们管他叫现金生涯本。可能是我们我我我们从这种这种描述微服务划分合理玻璃的情况的时候的时候的话，我们会叫做这种会把它看作是微服务啊，但是。

我们比如说从他的这种其他层次去去接受他的一些一种核核心的能力的时候，可能又会把它叫做中台。这可能是一种不同观点，不同从不同角度去看这个东西啊。另外这个这个中台它不是一个怎么说呢？可能它不是一个刻意而为之的这么一种现象啊就是。

有一段时间来讲的话，其实我们可以回避这个词就是中台啊，可能是觉得这个怎么说呢？是这个不适合啊这样这样一个观点。但是来讲话。他可能就是说他不是以你这个直观的意志来这个转移的啊，就是说当它形成的时候，它就是形成的就是你在做这个DDD的过程当中的话，它会自然而然的。

就会形成一个这么一个提供核心能力的这么一个服务。甭管你管他描述的是不是叫做中台。就是。再有一点呢，就是就像刚才我说的，就是基础服务这一层他会做的越来越厚实。那么发有一点啊，就是这个像这个BMF。他也有这种越来越挫越厚实的这么一种倾向啊。

为什么呢？其实来讲就是当我们这个业务比较稳定的这个时候啊，其实我们是并不习惯于就是这个。一个一个需求。比如说他这个调动的链路过长啊，调用的链路过深啊，其实来讲的话，这些都会使得这个我们这个交付效率变低。

啊，出错的这种概率变高啊，这种依赖的复杂度变高啊，都会出现这种事情。其实在我们这种有些业务的在这种怎么说呢？在这种。啊，在这一两周的这种这个实践过程当中的话，也遇到这个类似的这个情况。也遇到了类似的情况啊就是。

那么来讲呢，就是我们通过这种滴滴滴的这种方式啊，就是说是我们能够去认清自己的这个所在的层次，是一个什么样的层次啊，有。通过有边界的方式去做这种类似的对类似的这种事情。那么呢就是把一些业务聚合的一些聚合的逻辑放到BFF上去做。也就是把这个聚合逻辑放在偏下游的这个层次去做。

这样的话呢就是能够有效的去降低这种怎么说呢？这种系统的复杂度啊，然后使得这个这种交互的链路不至于过长。我认为就是说是这种怎么说呢？就是做的这种小小的这种中台啊，然后这种前台逐渐的这种坐后。啊，做大啊，这可能是一种在这种业务比较稳定，在这种高速公路的这种业务的这种形态下的话，是一个自然而然的这么一种。

变化啊，而不是一种刻意而为之的这么一种。变化。再有呢就是说我们在讲我们在讲中这种BFF层逐渐做厚啊，然后这种基础设施层逐渐做厚之后的话那。那其实业务中台层的这种人才啊，其实来讲的话，他们就会有更多的时间去这种思考自己的业务。

这一点的话其实就讲到了后面的一个问题。就是这种从这个技术负责人到项目流程中的这种主儿。就是啊这个也是今天讲最后一个事情。就是怎么讲呢？就是当我们这个怎么说呢？这种这种这样的这种业务方面的这种这种主要的这种核心的业务系统里面来讲话。我们需要有一些。

啊，人他不仅仅是这种什么什么什么深度的方向去发展啊，同时也需要像这种啊在做这种业务，同时能够做技术设计。同时能够做流程把控的这个方向去这个去去发展的时候。但是呢如果说通过我们的这种基础设施上，或者BMS能够有效的去降低这些人。

压力的情况下，那么这件事就会变得这个非常的可行啊。同时来讲的话，我们还会有另一个趋势，就是我们的其实在这种高速工作的这种阶段来讲的话，其实产品需要顾及的事情会越来越多。大家可以看到就是说从我的感受上面来看的话，也是就是说这种产品人员的话，其实他是。

能够怎么说呢？他其实是呃能够越来越少的有精力去入侵到这种真正的这种业务的这种开发的流程过程当中的。其实他需要把这种更多的这种精力留在自己的这种这种产品的思考啊，或者这种这种数据的这种分析和挖掘。我我点开点开这个这个阶段啊，所以也客观的也需要这种在这种啊业务的这种核心业务流程当中的话，有更多的这种呃这种技术人员。

能够这种负起这种主要的一个责任啊，其实来讲的话，这个也就是说我们在这种核心的这种怎么讲呢？就是这种这种这种在这种这种第一届这种核心领域的这种技术人员的话。就是说他所知道他所能够去呃关注的这个面儿啊，比篮球变得更宽啊，大概是这种这么一个意思。

好了好了，今天那个跟大家分享这个大概有将近50分钟的这个时间。老公。