目录

一、先把喧嚣放下：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 的基本概念（实体、值对象、聚合、限界上下文等），默认读者已有初步了解；需要回顾基础的读者，可以先翻一下文末参考文章里的理论总结篇。