目录一、先把喧嚣放下：DDD 到底值不值得（一）一套话术的三段式（二）复杂性的三种来源1、隐晦：难理解2、耦合：难改动3、变化：难扩展（三）DDD 能做什么、不能做什么1、把领域知识搬进代码2、什么时候不必用3、选择站队的前提二、营销系统的问题空间（一）四类用户与三个核心问题（二）四层模型与两个陷阱1、解决方案域的四层模型2、陷阱一：跳到数据模型3、陷阱二：跳到流程脚本（三）三段式落地路线三、战略设计：从用例到边界（一）确定用例1、四种表达方式2、营销系统的用例图3、二八原则（二）统一语言1、名词动词分析2、去伪存真、抽象合并3、术语表三件套4、七个标识的教训4.1 实验设计4.2 实验结果（三）梳理关系，形成概念模型（四）拆解子域1、三种拆法2、营销系统的五个子域3、核心、支撑与通用（五）上下文映射与防腐层1、映射关系一览2、营销系统的上下文图3、防腐层长什么样（六）验证与迭代1、场景走查2、业务预判3、迭代的三个来源四、战术设计：从概念模型到对象模型（一）三种映射1、概念分层用继承2、概念关系用组合3、概念状态用状态机（二）实体与值对象（三）聚合根的粒度1、小聚合2、大聚合3、适度封装4、三条原则（四）仿真实测1、实验设计2、结果解读3、局限与延伸（五）领域服务与充血模型1、领域服务放什么2、充血还是贫血3、方法名说业务话（六）营销系统聚合全景五、代码架构：把设计映射为实现（一）三种架构，同一个圆心（二）营销系统的分层落地1、用户接口层2、应用层3、领域层4、基础设施层5、通用层（三）工程结构与依赖守护1、模块与包2、用测试守护依赖方向（四）一次请求的旅程六、他山之石：交易系统的分层演进（一）交易系统的分层（二）从订单耦合到上下文拆分1、过度耦合2、贫血症与失忆症3、演进式拆分（三）同与不同七、常见误区与落地清单（一）四个误区（二）落地清单（三）如何衡量收益八、结语参考文章干货分享，感谢您的阅读！一个需求从会议室走到生产环境，中间要经历好几次"翻译"：业务方讲的是玩法，产品把玩法整理成功能，研发把功能拆成类和表，最后再变成一行行代码和一张张表结构。每一次翻译都可能丢掉一点业务含义——业务说"档位"，代码里叫rule；业务说"商户"，系统里有七种 ID；业务说"改了库存要重新审批"，代码里只有一句updateStatus(2)。丢得多了，系统就会变成只有原作者能看懂、改一处坏三处的样子。领域驱动设计（Domain-Driven Design，以下简称 DDD）要解决的，恰恰是这个"翻译损耗"问题。它并不神秘：先和业务一起把概念说清楚，形成统一语言和概念模型；再把概念模型拆成边界清晰的子域与上下文；然后把概念映射成实体、值对象、聚合和领域服务；最后用分层架构和依赖倒置把这些设计落成代码。本文以一个面向商户的 B 端营销系统为主线，把这条链路从头到尾走一遍：哪些步骤真正有用、每一步该交付什么、聚合到底该切多大、代码该怎么分层，并配两段可运行的 Java 程序，用实测数字说明"统一语言"和"聚合粒度"这两件看似务虚的事，在工程上究竟值多少。这里不展开 DDD 的基本概念（实体、值对象、聚合、限界上下文等），默认读者已有初步了解；需要回顾基础的读者，可以先翻一下文末参考文章里的理论总结篇。