TIL DDD战术模式：用Clojure让代码说人话

是什么

先花一分钟搞清楚 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 把它们写进代码，不可绕过。

所以回到那个问题——"用业务语言表达函数和方法"是第一层，第二层是"用恰当的数据结构区分业务概念"，第三层是"用代码边界强制执行业务规则"。三层加起来，让代码替你说出业务在干什么。

暗无天日