目录
是什么
先花一分钟搞清楚 DDD 在说什么。
DDD（领域驱动设计）是一套软件设计方法论，核心观点是： 写代码之前，先搞清楚业务 。它分两层：
- 战略 DDD ：划定领域边界（这个系统管什么、不管什么），和业务专家定义一套统一语言，同一件事，代码里和会议上叫同一个名字
- 战术 DDD ：用具体的编码模式把业务理解落实到代码里。本文讲的 Entity、Value Object 这些，就是战术模式
战略先搞清楚"是什么"，战术再回答"怎么写到代码里"。如果反过来，先设计数据库表再想业务，代码迟早变成一堆 getThing() 和 setThing() 。
代码烂掉，绝大多数时候不是因为写得差。
真正的原因更简单：三个月后你打开那段代码，你已经不知道它当时在解决什么业务问题了。函数名叫 handle-alert ，但你不知道它是升级告警、静默告警还是只是打印日志。注释早就过期了，commit message 只写了"fix"。
DDD 的战术模式要解决的就是这个问题。它不关心你用了什么框架、数据库、消息队列，它只坚持一件事： 代码结构本身应该说出业务在做什么 。
为什么
(defn handle-alert [alert-id new-level]
(let [alert (db/find :alerts alert-id)
old-level (:level alert)]
(when (should-escalate? old-level new-level)
(db/update! :alerts alert-id {:level new-level})
(notify-team (:team-id alert) new-level)
(log/info "alert" alert-id "escalated from" old-level "to" new-level))))
此示例为概念示意，函数 db/find 、 should-escalate? 等未定义，不可直接执行。
代码能跑，但你一眼扫过去，脑子里全是问题：
- "升级"规则是什么？
should-escalate?里的逻辑为什么长这样？ notify-team和db/update!为什么非得捆在一起？能不能只升级不发通知？alert那张 map 里到底有哪些字段？什么变了还算是同一条告警，什么变了就不再是？
这段代码没有 bug，SQL 也没毛病。问题是 业务意图在代码里找不到地方落地 。DDD 的战术模式就是给这些意图分配明确的"住处"。
怎么做
这里用告警系统的场景来展示八个模式。例子用 Clojure。
Entity：对象由身份定义
告警规则（ AlertRule ）是典型的 Entity，改名字、改阈值、改级别，只要 :id 不变，它就是同一条规则：
(defrecord AlertRule [id name query-expr level]) ;; 同一条规则，:id 不变，name/level 改了也认它 (def cpu-rule (->AlertRule "r-cpu-001" "CPU过高" "cpu>90" :p1)) (def cpu-rule-v2 (->AlertRule "r-cpu-001" "CPU过高-改" "cpu>95" :p0))
cpu-rule id: r-cpu-001 name: CPU过高 level: :p1 cpu-rule-v2 id: r-cpu-001 name: CPU过高-改 level: :p0 Same id? true
defrecord 在这里的实际作用是给读代码的人一个信号：这东西有独立身份，不要用 assoc 随便改它。
Value Object：对象由值定义
告警级别 P0 、 P1 、 P2 不需要身份。只要值相同，它们就是同一个东西，典型的 Value Object。在 Clojure 里用 clojure.spec 约束：
(require '[clojure.spec.alpha :as s])
(s/def ::alert-level #{:p0 :p1 :p2 :p3})
:p1 valid? true :p5 valid? false :urgent valid? false
不用 spec 的时候，级别就是一个裸 keyword，你靠什么拦着别人写成 :p5 或者 :urgent ？spec 把"告警级别只能有这四个值"这条 业务规则 钉在代码里，而不是在开发者的脑子里。
Aggregate Root：访问聚合的唯一入口
告警通知组（ AlertGroup ）是一组告警规则的集合。要求是：外部不能直接捅进 :rules 字段里增删规则，必须走 add-rule / remove-rule 。这层控制不只是一个技术约束——=add-rule= 这个名字本身就是业务语言，它在说"往组里加规则"是一件合法的业务操作。以后加校验（比如一个组最多 10 条规则），只改这两个方法就行。
(defrecord AlertGroup [id name rules]) (defn add-rule [group rule] (update group :rules conj rule)) (defn remove-rule [group rule-id] (update group :rules #(remove (fn [r] (= (:id r) rule-id)) %))) (defn get-rules [group] (:rules group))
After adds, rules count: 2 After remove r-001, rules count: 1 Remaining rule id: r-002
add-rule 和 remove-rule 现在可以在代码库里被 grep 到了。它们是有名字的业务操作，将来搜 add-rule 一眼就能看出谁在往通知组里加规则。
Domain Event：事件是领域的一等公民
告警升级不是一段逻辑，它是一个 已经发生的事实 。把它变成一个显式的 record，代码中发生升级的位置只管创建这个 record。至于创建之后谁来读取、读取之后做什么，是发通知、记统计、写审计日志都由关心它的模块各自处理，互不耦合。
(defrecord AlertEscalated [alert-id old-level new-level escalated-at group-id])
;; 升级逻辑只负责"产出事实"
(defn escalate [alert-rule new-level]
(let [event (->AlertEscalated (:id alert-rule)
(:level alert-rule) new-level
(java.time.Instant/now)
(:group-id alert-rule))]
;; 更新状态
;; (publish-event! event) ; 依赖具体实现，此处仅示意发布位置
event))
Event alert-id: r-001 Event old-level: :p1 Event new-level: :p0 Event escalated-at type: java.time.Instant Event group-id: g-001
AlertEscalated 的存在本身就是文档：一看就知道"这个系统有告警升级这回事，并且升级时会记录哪些信息"。
Factory：封装创建逻辑
创建一条告警规则看起来只是 new AlertRule() ，但实际上要生成 ID、校验级别合法、可能还要设默认值。这些逻辑如果散落在各处，新手拷贝代码时就很容易漏掉校验。Factory 把创建规则集中起来进行管理：
(defn create-alert-rule [name expr level]
{:pre [(s/valid? ::alert-level level)]} ;; 业务校验：级别必须合法
(->AlertRule (str (java.util.UUID/randomUUID)) name expr level))
Created rule id: da2eaeb7-... name: 磁盘告警 level: :p1
注意 :pre 那行。如果你传了个 :p5 进去，函数直接抛错，不会让一条非法规则进入系统。这条校验原来可能在 Controller 里写一次、在 Service 里又写一次，现在 Factory 替它们干了。
Repository：隔离领域与持久化
业务代码不需要知道数据存在 PostgreSQL、MongoDB 还是内存里。它只需要说"存这个组"或者"按 id 查这个组"。Repository 定义一个接口，实现细节隐藏：
(defprotocol AlertGroupRepository (save [this group] "持久化通知组") (find-by-id [this id] "按 id 查询通知组"))
Found group: 基础设施
上面这个 defprotocol 只是契约。测试时用内存实现，生产环境换成 Postgres，业务代码不用改。更关键的是， save 和 find-by-id 这两个方法名本身就是业务语言：你在存一个通知组、查一个通知组，不是在写 SQL。
Domain Service：无处可去的领域逻辑
"把一条规则从 P2 升级到 P0"这个操作只涉及规则本身，不关别的事。但有些逻辑天生跨多个对象。"把一条规则从 A 组迁移到 B 组"就同时涉及源组和目标组，这个方法放哪边都不对。Domain Service 用来收容这类无处安放的业务逻辑：
(defn escalate-alert [rule new-level]
{:pre [(s/valid? ::alert-level new-level)]}
(assoc rule :level new-level))
(defn transfer-rule [rule source-group dest-group]
(->> source-group
(remove-rule (:id rule))
((fn [src] [(add-rule dest-group rule) src]))))
Original level: :p2 → escalated level: :p0
escalate-alert 和 transfer-rule 都是纯函数，输入规则，输出新状态。不碰数据库，不发消息，不调 API。这是 Domain Service 和 Application Service 的关键区别：Domain Service 只管业务规则本身——输入什么，输出什么。输出之后要不要存起来、要不要通知别人、要不要发消息，这些由 Application Service 来管。
Application Service：编排用例步骤
业务规则写好了、持久化接口有了、事件类型也定义了，谁来把它们串成一条完整的业务流程？Application Service 干的就是这个，它是指挥，不是执行者：
(defn handle-escalation [repo rule new-level]
(let [escalated (escalate-alert rule new-level) ;; 1. 执行业务规则
group (find-by-id repo (:group-id rule))]
(save repo (update-group-rule group escalated)) ;; 2. 持久化
(publish! (->AlertEscalated (:id rule) ;; 3. 发事件
(:level rule) new-level
(java.time.Instant/now)))
escalated))
Published: AlertEscalated old-level: :p2, new-level: :p0
注意 handle-escalation 自己不包含任何业务规则，它只是把 Domain Service、Repository、Event 按顺序串起来。往后加审计日志或者加事务控制，改这一个函数就行，不用满项目找。
多说一句：DDD 的核心到底是什么
看完八个模式，一个自然的印象是：DDD 不就是用业务语言来给函数和方法起名吗？
这个直觉对，但不全对。DDD 实际上有三层：
第一层：语言一致。 函数叫 escalate-alert 而不叫 handle-alert ，方法名叫 add-rule 而不叫 update-list 。代码里的词就是会议上用的词。这一层 Clean Code 也在做，DDD 真正的穿透力在后面。
第二层：结构映射。 *Entity 和 Value Object 的区别不是命名习惯：Entity 有独立身份，改了属性还是它自己；Value Object 没有身份，值一样就是同一个东西。如果把一切东西都当 Entity（全都有 ID），或者全都用裸 map 不管有没有身份，你不会损失可读性，你损失的是 * 业务分类在代码层面的表达力 。
第三层：约束写进代码。 Factory 的 :pre 校验保证"级别只能是 P0-P3 这四个值"，不经过 Factory 就创建不出一条非法规则。Aggregate 的 add-rule / remove-rule 保证外部永远只能走这两个入口修改通知组。这些约束原来在开发者脑子里、在团队约定的文档里、在 code review 的 checklist 里，DDD 把它们写进代码，不可绕过。
所以回到那个问题——"用业务语言表达函数和方法"是第一层，第二层是"用恰当的数据结构区分业务概念"，第三层是"用代码边界强制执行业务规则"。三层加起来，让代码替你说出业务在干什么。