简介这套DDD领域驱动设计PPT以业务领域建模为核心面向中高级开发与架构设计人员系统讲解DDD的分层架构、子域与限界上下文、实体/值对象/聚合等关键概念并结合智慧城市、产业互联网等复杂业务场景说明如何借助事件风暴划分微服务边界、规避“过度拆分”与“拆分不足”的风险。内容从软件流程痛点切入在对比瀑布与敏捷开发后引出DDD与中台建设的关系图文并茂地呈现聚合设计原则、领域事件驱动方式有助于理解“业务模型与代码模型一致性”的落地思路。资源为1个pptx演示文稿压缩包大小3.73MB无需解压多文件即可获得完整内容已有304人学习下载。适合在团队内训、技术分享或微服务方案评审前快速梳理DDD理论框架与实施要点。1. DDD领域驱动设计PPT一份能直接上会的领域建模讲义资源某天下午一位后端同事跑过来问团队里几个开发对订单状态该由哪个服务来改吵了一周架构图上画了十几个微服务代码里却是另一回事。他想做一次技术分享把领域驱动设计的建模思路讲清楚但翻了半天资料发现要么太理论要么全是代码。这份DDD领域驱动设计PPT属于能直接拿来上会的那一类它把战略设计的边界分析和战术设计的落地写法整理成了一套可翻页、可讲解、可讨论的讲义框架。适合要做技术分享的后端开发、想给团队统一建模语言的架构师也适合准备面试时快速梳理DDD主线的人。重点不是“背概念”而是照着讲稿就能推进一次有效的建模讨论。2. 这套PPT怎么读先拆解再本地化别拿到手就从头放到尾很多资料型PPT的常见死法是下载后花了二十分钟看完感觉都懂真到要讲的时候又不知道该强调什么。我的习惯是拿到这类DDD领域驱动设计PPT第一件事不是翻页而是先判断它的结构能不能支撑一场完整的讨论。一套合格的DDD讲义至少要把“为什么建模”讲在“怎么建模”前面否则听众很容易陷入术语沼泽。2.1 先抓骨架战略设计这组页面是整个材料的锚点大多数DDD主题PPT会按两条线组织战略设计和战术设计。战略设计处理的是“系统和系统之间怎么划界”战术设计处理的是“边界内部怎么建模”。如果PPT里只看到实体、值对象、聚合、仓储这类战术词汇而没有限界上下文、上下文映射、子域这些战略概念那它可能只是把领域驱动设计的代码模式抽出来讲了一遍并不是一套完整的建模讲义。真正能用的材料会把战略设计放在前面因为多数团队的问题根源不在类写得不好看而在模块边界本身就没想清楚。拿到PPT后我一般只做三遍速读第一遍只看章节标题确认有没有出现“限界上下文”“统一语言”“事件风暴”这几个词第二遍看案例页用的什么业务场景判断它离听众的业务远不远第三遍看每页是“概念解释”还是“决策引导”。概念解释页占比过高的PPT讲起来会很累需要你自己补互动点。一套可以上会的PPT至少得有三分之一页面是让你停下来问问题的。比如放出一个电商订单的上下文映射图就值得停下来问“为什么支付和库存是两个限界上下文而不是一个”表格在这里比较好用。我拆过一份DDD讲座材料发现内容可以分组成四块背景铺垫、战略设计、战术设计、落地映射。背景铺垫回答“为什么用了微服务还是乱”战略设计回答“边界画在哪、怎么画”战术设计回答“边界内的建模元素怎么表示”落地映射回答“代码目录和团队结构怎么对应”。讲的时候背景铺垫控制在十分钟内战略设计占四成时间战术设计占三成落地映射留两成最后留十分钟讨论。别反过来一上来就讲聚合和仓储听众通常会在“这个聚合根为什么这样设计”上卡住。2.2 下载后的第一项改造把页面备注栏当成讲解稿来写我见过不少人下载了一份好的PPT结果直接原封不动放出来讲听众反馈是“知道你在讲领域驱动设计但不知道关我们什么事”。问题不在PPT本身而在没有做本地化。拿到资源后的第一步不是改样式而是把每一页的备注栏填满。备注栏里写三样东西这页的核心结论、要讲的项目例子、要向听众抛出的一个问题。比如一页讲“聚合设计原则”的PPT核心结论写成“修改必须能在一个事务里完成否则要怀疑边界画错了”项目例子写成“某个订单服务一次提交改了订单、明细、对账单三张表就应该把这三块收进同一个聚合或重新划分”抛出的问题写成“我们的订单模块最近一次上线涉及几张表”这一步非常关键。尤其当你要把这份PPT讲给“只听过DDD但没写过的团队”时备注栏里那句“不要为了上领域驱动设计而造一个大聚合”往往比幻灯片正文里的原则更有价值。我一般会要求自己一页PPT备注不超过四句话否则讲的时候容易照着念。备注一旦写满这份PPT就从一个“别人讲过的材料”变成了“你自己的工作笔记”后续再讲第二次只需要更新案例不需要重做整套片子。做本地化还有一个常见手法把PPT里附带的示例业务换成自己正在做的业务。比如原材料用的是图书借阅系统听的人不熟悉业务域你就很难从他们脸上看到共鸣。换成他们每天都在维护的订单、库存、商品中心哪怕模型粗糙一点讨论也会比原来激烈得多。这里有一个参数可以控制替换案例时不要只换名词把故事线也换掉。图书借阅的“借书-还书-逾期”是一条完整流程换成订单就要重新梳理“下单-支付-发货-收货”哪些动作产生领域事件、哪些状态可以被其他上下文订阅。只有把整个事件链走一遍替换才算完成。3. 怎么用这套PPT做一次内部技术分享三种时长与四种听众的应对同样一份DDD领域驱动设计PPT在二十分钟的技术双周会和一下午的建模工作坊里用法完全不同。这个章节给出我常用的切分方式以及针对不同岗位的讲解侧重点。内容结构上核心思路是用“战略设计引导问题战术设计补充代码落地映射部分形成可执行结论”。3.1 三种时长版本15分钟、45分钟、90分钟怎么切先说15分钟版本。这适合技术分享会或项目预评审目标不是教会建模而是让听众意识到“业务边界需要专门讨论”。我会只挑三类页面讲一页说明“为什么照着数据表设计微服务会翻车”一页展示“限界上下文和微服务边界的关系”一页给出“一个订单拆成三个上下文”的示意图。剩下的时间全部用来抛出那个问题我们现在的系统里哪些模块看起来像一个上下文实际上混了两个职责在这个时长里统一语言、聚合等战术内容全部略过不展开讨论。45分钟版本是最常用的适合一次正式的部门内技术分享。我会按“10分钟背景 → 20分钟战略设计 → 10分钟战术设计 → 5分钟映射”来切。战略设计部分必须讲透先讲事件风暴如何发现领域事件再讲如何从事件反推聚合最后说明上下文映射如何表达系统间的关系。战术设计部分只挑实体、值对象、聚合、仓储四类建模元素讲每类用一个代码片段或类图对应上。映射部分给出一张目录结构图把聚合、领域服务、应用服务、基础设施代码分别放在哪个包层让人看到一个聚合从事件到代码是怎么落地的。这套组合拳打完至少有一半人会开始讨论自己项目里的边界划分问题。90分钟版本实际上是半天的建模工作坊。45分钟讲完PPT剩下45分钟把某条业务线拉出来做一次现场精简版事件风暴。我不会用真实线上系统而是挑一个大家都熟悉的“模拟项目X”场景比如“工单系统”参与者围坐在一起把“创建工单”“指派处理人”“提交解决方案”“关闭工单”这些动作写成卡片贴在白板上。然后组织者引导大家圈出聚合边界、找出领域事件、标出哪些模块其实属于另一个上下文。95%的情况下第一次做事件风暴的团队会在“工单状态应该由谁改”这个问题上争论起来这场争论就是PPT最好的收尾比多讲二十页幻灯片都有价值。3.2 给后端、给前端、给产品、给管理讲侧重点完全不同同一套PPT不能对所有听众都用同一套讲法。给后端开发讲重点放在战术设计尤其聚合根、仓储和事务边界。后端最关心的是“我的这张表放在哪个聚合里、能不能直接跨聚合改数据”。给前端讲重点放在统一语言和查询模型因为前端更关心“接口返回的字段和业务概念是否对上”以及查询场景如何通过独立的读模型解决。给产品经理讲重点放在事件风暴和限界上下文因为产品经理每天面对的是业务流程和不明确的职责归属DDD里最有价值的是帮他们把“谁负责什么”画成一张人人都认的图。给管理者讲则要切换到项目视角。不说“聚合”和“值对象”而是说“模块边界”“团队协作成本”“系统间接口数量”。限界上下文这个术语可以保留但要用一句话解释清楚它是一套业务规则的适用范围也是团队组织边界的参考。管理侧最怕听到“我们要引入一套新方法”所以要强调DDD不是新技术栈而是让现有系统按业务边界重新划分的思考框架。通常我只需要把上下文映射图和微服务拆分方式对应起来管理者就会自己算出来哪些服务其实应该合并哪些团队之间天天扯皮是因为业务边界压根没划清。这一节的关键是调整术语密度。对非技术听众每个英文术语第一次出现都要附一个业务例子。例如“通用语言”这个词对产品经理应该说成“每个概念在业务上只有一个名字不搞一堆叫法”而不是“统一词汇表”。给开发讲时再补上代码层面的含义。4. 避坑与排查讲DDD最容易翻车的四个现场与解法用PPT只是起点真正想清楚的人不会一上来就讲“实体与值对象”。以下四个问题是我在多次内部培训和复盘里见过的真实现象拆解开来看原因再给排查方向。4.1 现象讲了一个半小时反馈“还是很抽象”一次分享结束后好几个人说“DDD确实很重要但我不确定明天怎么开始用”。这个反馈几乎可以断定整场内容只有概念没有“从哪个具体动作开始”。原因通常不是听众理解力不行而是幻灯片里缺少一个贯穿始终的负面例子。光讲“聚合应该小”大家没有参照物讲“这个订单聚合一开始装了太多东西最后不得不拆成三个因为一次事务要锁太多行”效果立刻不一样。我后来养成的习惯是在每章正式概念前先放一屏“错误做法”的截图比如一段把所有业务逻辑写在服务层、把领域层掏空的代码。先让大家看到那个熟悉的黑匣子再讲正确的建模方式抽象感会消掉大半。排查方向是如果讲完PPT第三天团队里没有人主动画出一张限界上下文图说明案例和他们的工作脱节了。解决办法是找一个他们上周刚上线的小功能现场把它的事件链列出来哪怕只列出起止事件也能把“抽象”拉回到“可操作”的层面。4.2 现象限界上下文画成了组织结构图团队里有一个常见错误把订单上下文、库存上下文、用户上下文画完后大家发现这几乎就是公司的部门架构。开发负责人看完说“我们早就这么分了”但显然他们还在为跨部门的数据一致性吵架。原因是把限界上下文和“团队职责”画了等号但边界划分的依据不应该是“谁负责这个模块”而应该是“业务规则在哪里是完整独立的”。比如一个网上商城库存数量在“商品中心”里是一个可查询的展示值但在“订单中心”里它参与的是扣减与释放的过程。这两个场景对“库存”这个概念的业务规则是不同的。如果照着部门边界画就会把库存这个上下文画成两个团队各管一半导致每次扣减库存都要跨越上下文做同步。排查方向问一个简单问题——“当库存不足时系统是否允许再下一单”如果订单中心和商品中心各有一套判断逻辑说明库存这件事应该有一个独立的上下文而不是顺便挂在两个部门头上。划线时要先确认这个上下文能否自己独立解释一组业务规则再看它归属于哪支团队。很多情况下一个上下文会拆给多个团队也可能一个团队维护多个上下文不能机械对应。4.3 现象聚合边界一落地就走样PPT里讲聚合讲得头头是道结果代码一写开发还是把订单、明细、支付单、物流单全部塞进一个大聚合里导致每次保存都要锁一大片表数据库经常出现死锁。另一个极端是每张表都是聚合根所有领域服务都在做“跨聚合编排”事务边界完全消失。原因有两个。一是PPT没有把“事务边界”和“聚合边界”绑在一起讲清楚。聚合不是一种代码分组方式而是一个一致性边界一个聚合内的对象必须在一个事务里保持最终一致。二是没有给出判断标准导致只能凭感觉画。我在讲解时给出的标准很简单问一句“这个操作如果中途失败哪些数据必须一起回滚”需要一起回滚的就是一个聚合的一部分可以接受异步最终一致的就拆成不同聚合。排查方向让开发把最近一次接口的写入路径截图出来看一次请求里改了几张表。如果改了三张以上而这个修改不能容忍部分成功那这个聚合基本就是画大了。反过来如果两个对象永远都是一起操作、一起更新却被设计成两个聚合说明边界画小了结果是把简单的强一致操作硬拆成跨聚合事务徒增复杂度。用事务边界反查聚合是避免这套PPT内容“讲完就忘”最有效的验证方法。4.4 现象统一语言变成了英文术语词汇表不少团队讲完DDD之后最明显的“成果”是大家记住了“聚合根”“仓储”“领域事件”这几个词。过了两个月代码里仍然叫“orderInfo”“userCenter”业务需求文档里仍然叫“订单信息”“用户中心”两边各讲各的统一语言变成了英文名词大杂烩。原因是PPT把统一语言讲成了“一个概念对应一个英文术语”而统一语言的本质是让跨角色的沟通有共同含义。它应该包括业务术语、命令词、事件名甚至还包括“哪个词不允许再用”。比如“订单”这个术语如果业务、产品、开发都认可“订单只指用户一次购买行为生成的单据”那么“购物车里的东西”就不能叫“订单”哪怕数据库里有一张cart表也不该在业务沟通里用“订单”代指。这个否定性的约束比背十个英文词条更有价值。排查方向在分享结束前拉一个“命令词表”出来每一行写“动作 / 发起角色 / 产生的领域事件”。例如“取消订单/用户/订单取消事件”要求参与者在白板上把最近一个需求的命令词写出来。如果写出来的词各不相同就说明统一语言还没有真正确立。在PPT里加一页“反面对照表”比反复强调“统一语言”四个字有用得多。5. 终章讲完PPT之后做一个“反例拆解”实验验证团队会不会建模在分享了数十场之后我发现最能检验一个人有没有真正理解DDD的指标不是他能说出多少术语而是他能不能一眼看出一个错误的模型为什么错。这个环节适合放在内部培训的结尾也可以作为技术评审前的一次热身。5.1 反例拆解三张表、五个步骤、十五分钟验收操作方式不复杂准备一个故意画错的限界上下文图或聚合模型让参与者单独或分组找出问题。我常用的是一个订单压测场景一页图上画了一个“大订单聚合”包含订单头、订单明细、支付记录、发货记录、开票信息。请参与者在十五分钟内回答三个问题这个聚合存在哪些问题哪些对象应该独立成其他聚合如果要拆事件流应该从哪个事件开始重新建模参考分析思路写在表格里检查对象常见问题拆分的信号聚合内对象对象之间生命周期不一致发货记录的状态不依赖订单头状态应独立事务边界一次操作要改五张表才能完成需要跨聚合的异步补偿说明边界过大领域事件找不到明确的“业务已发生”事件没有事件说明模型没有反映实际业务流程上下文归属同一个概念在两个上下文里的行为被混淆库存既是“可售量”又是“可扣减量”需要区分来源我在指导这类实验时要求各组只能给出“拆分结论依据的事件名”不能直接讨论表结构。比如提醒参与者“如果开票和支付状态没有直接因果就不适合和订单头放在一个聚合里可以考虑让支付上下文在支付成功时发布领域事件订单上下文订阅它。”也就是说用事件而不是外键来表达关系这就是理念差异带来的边界变化从“外键视角”迁移到“事件视角”恰恰是这套PPT落地成能力的关键一步。这个反例实验最终要得到两个可知的产出。一是画出一张修正后的聚合划分图二是列出这个修正会影响的领域事件序列。如果团队能在十五分钟内完成这两项说明这场分享不是“听过就忘”而是建模能力的一次真实更新。如果没有完成也不要急着再讲一遍PPT更有效的方式是回到事件风暴步骤把“谁在什么时刻发出什么命令、最终改变了什么状态”从头顺一遍通常卡住的位置就是理解断层所在。从那以后我每次用这类DDD专题PPT做内部培训都会强制走一遍这个反例拆解流程无论时间多紧都不砍掉最后十五分钟。因为讲完知识和把知识用起来之间差着一场高质量的“找错”练习而找错之后团队的边界讨论会从“我觉得”变成“按事务边界或事件流推导”。这十五分钟是我认为整套PPT里最值回票价的一段希望帮到你。本文还有配套的精品资源点击获取