简介面向软件架构师与后端开发者的DDD领域驱动设计详解PPT系统讲解领域驱动设计的核心概念与实践方法主要解决复杂业务建模、中台建设以及微服务拆分时边界不清、粒度难定等典型问题。课件从DDD分层架构切入逐层说明表现层、应用层、领域层与基础设施层的职责并重点拆解实体、值对象、聚合、聚合根和限界上下文等关键要素及其协作关系。内容结合智慧城市、产业互联网等真实业务场景演示如何通过事件风暴完成从业务事件到命令、领域对象再到聚合边界的收敛过程同时给出聚合设计五条原则与领域事件驱动设计思路对落地微服务拆分、确定微服务边界和保持领域模型一致性有直接指导作用。压缩包共1个pptx文件大小3.73MB结构紧凑便于快速通读。已有304人学习适合正在引入DDD或优化微服务架构的设计与开发团队。1. DDD领域驱动设计PPT不是讲课稿是一套能逼你做出决策的建模地图做 DDD 分享最容易翻车的地方不是没讲清聚合是什么而是 PPT 页面顺序按书目录排——概念、术语、原则一路讲下来听众前 10 分钟还能跟上后面全程走神。你问他们记住了什么回答往往是“挺有道理的就是不知道回去怎么用”。这就是 DDD 领域驱动设计 PPT 最大的问题它太容易做成一堂知识普及课而听众真正要的是“我该从哪里下手改我的项目”。这份材料真正适合三类人要给组内做技术分享的开发者、要向上汇报架构方案的负责人、要把 DDD 引入新项目的技术决策者。它不是一个能直接下载的成品 PPT而是一套可复用的骨架——用战略设计的限界上下文来切章节、用战术设计来定每一页的图形规范、用时间预算来控制讲解节奏。你照着这个思路排页面、画图、写讲稿出来的东西既能当培训材料也能当评审文档。核心主张只有一句话一份合格的 DDD 演示材料不是把知识讲完而是让听众走出会议室时手里有一张明确的“下一步行动清单”。要做到这一点PPT 的叙事顺序必须从“DDD 有什么”改成“你的项目哪里在痛DDD 的哪个工具能止疼”。下面五章我按做这套材料的实际工序来写。2. 先搭战略层骨架用限界上下文把PPT的章节地图定下来2.1 为什么PPT结构要抄限界上下文而不是抄目录限界上下文是 DDD 里最容易被低估的概念。它划定模型的有效边界一个模型在某个上下文里含义清晰出了这个边界就要重新解释。做 PPT 也一样一套演示材料其实就是一个“讲解的限界上下文”每一章都只负责回答一个边界明确的决策问题。常见做法是照着书目录排页面是什么、为什么、核心概念、战略设计、战术设计、案例。这种线性结构在读书时没问题但放在汇报场景里就是灾难。听众是带着问题来的你按知识体系讲他们就只能被动接收无法在心里把内容映射到自己手头的系统上。我一般会先把听众想解决的问题列出来反推章节顺序听众想知道“DDD 能不能解决我们现在的混乱” → 开场放业务痛点听众想知道“DDD 和微服务怎么配合” → 用上下文映射图讲清边界听众想知道“代码里怎么落地” → 战术设计放在项目改造案例之后听众想知道“我回去第一步做什么” → 结尾必须给行动清单所以整套 PPT 我建议切成六个模块页数控制在 30 到 45 页。太薄讲不清建模过程太厚听众注意力撑不住。下面是页面分配清单可以直接抄模块建议页数页面内容取向视觉重心引入业务痛点3-4 页用具体业务描述“规则失序”的现象痛点故事线、问题列表战略层边界与通用语言8-10 页限界上下文、上下文映射、通用语言上下文地图、映射关系图战术层模型要素10-12 页实体、值对象、聚合、领域服务图例规范、模型示例落地改造路径6-8 页从现状到目标的分步演进前后对比、阶段计划表复盘与问答3-5 页常见误区、提问预案问题清单、决策要点行动清单1 页听众回去第一步做什么三步行动项这个结构的内在逻辑是先让听众承认痛再给出边界工具再落到代码要素最后收在行动上。每一章在讲下一章之前已经把上一章留下的“所以呢”回答完了。2.2 开场三页先让台下承认“我们有病”第一页不要放标题放一个具体的业务现象。比如一个订单系统改一个配送逻辑要动五个服务每次上线都胆战心惊——这种描述比“我们的系统耦合严重”有力得多。第二页把这个现象翻译成一个问题业务规则到底该由谁来表述、谁来负责实现第三页才引出 DDD 的切入点问题出在语言不统一和边界缺失DDD 的第一工具是通用语言和限界上下文而不是聚合。这三页是整套 PPT 的“战略设计”它们定义了整场分享的限界上下文——我们只讨论“如何用 DDD 梳理业务模型并落到代码结构”不讨论具体框架选型不讨论部署架构。这个边界不划清后面任何一页都会被人追问扯远。开场三页里最容易犯的错是急着把 Eric Evans 原书里的术语搬出来。听众对“通用语言”四个字没有感知但对“需求和开发说的根本不是一回事”有强烈共鸣。所以表达顺序一定是现象优先术语滞后。2.3 收尾一页行动清单才是PPT的“领域服务”领域服务在 DDD 里承担着“不属于任何实体和值对象的业务动作”这一定位。PPT 的收尾页也应该承担类似职责它不属于某一张概念页而是把整场内容转化成一个可执行的业务动作。我会在最后一页放三行字带编号但不用复杂表格“梳理你的核心域找出最痛的一条业务链路组织业务方和开发开一次事件风暴工作坊从这条链路里挑一个聚合做战术建模写进迭代计划。”每一行都是一个独立的后续动作且能和前面讲过的某一章对应上。听众如果只带走一页带走这张就够了。如果听众里有能做决定的人再加一句把这次分享当作一次启动会而不是一次培训。启动会意味着接下来要有计划、有分工、有验收标准培训则没有。3. 战术层图形化实体、值对象、聚合的三种标准画法3.1 统一图形规范同一页里只允许出现一套图例PPT 里画 DDD 模型图最大的问题是每个人画得不一样。有人用矩形表示实体用菱形表示服务下一页又换了颜色体系听众每看一张图都要重新学一套语法。这恰恰违背了 DDD 通用语言的精神——图形本身就是一种通用语言必须全篇保持一致。我建议固定下来这样一套最小图例不需要额外学习成本任何画图工具都能画模型要素图形关键标注反面示例实体 Entity直角矩形左上角标:Entity内含唯一标识 ID只写类名不标 ID值对象 Value Object圆角矩形左下角标:VO内含属性集用直角矩形和实体混淆聚合 Aggregate粗边框虚线大矩形顶部标聚合名称内部含实体和值对象用普通矩形把多个类装进去领域服务 Domain Service圆圈或带圆角六边形标动作短语如计算运费用类图标表示聚合根 Aggregate Root实体矩形加粗边框标AggregateRoot且仅一个聚合内出现两个粗边框这套规范的要点是聚合根必须视觉上异于普通实体否则听众无法一眼看出“这个聚合从哪个入口访问”值对象必须圆角化和实体形成对比领域服务的图标只出现在跨实体动作上不要给每个方法都画一个服务。实战中我常用某个可视化建模工具画完导出 PNG 再贴进 PPT也见过有人直接用表格工具绘制模型关系。不管用哪套工具把上面五个图例存成一张“图例卡”放在 PPT 附录页分享时如果有人中途进来可以直接翻到附录补上下文。这个细节在长培训场合尤其好用。3.2 用脚本批量生成模型图最少代码统一所有页面的视觉手工画图的痛点是改一处就要重画三张而且不同页面的图风格容易跑偏。我的做法是把聚合模型用一段脚本定义成结构化数据再批量生成示意图。常见做法是用可视化工本文还有配套的精品资源点击获取