领域与语言：领域、模型、统一语言三块地基

全章用同一个贯穿全书的例子：「云市」电商交易平台。云市要做的生意是——买家挑商品、下单、付款、发货、签收。这门生意背后有五个职责分区（目录、销售、库存、配送、支付），但本章先不拆边界，只用它来钉死三个最基础的词：什么是这门生意本身（领域），什么是你为它建的那套抽象（模型），以及怎么让说生意的人和写代码的人用同一套词（统一语言）。

1.1领域 Domain：是"问题"，不是"软件"

领域（Domain）是你要解决问题的那块真实业务世界本身——云市这门生意，而不是你为它写的代码。

把这层说穿：领域是问题，软件是你提交的一个解。云市的领域，是"在一个交易平台上，让买卖双方安全地完成一笔买卖"这件事——它包含商家定价规则、库存怎么算可用、订单一旦确认就受什么约束、钱货怎么对得上。这些事实在你写第一行代码之前就存在，也独立于你最终用 Java 还是 Go。你写的 OrderService、那张 t_order 表，是你对这个领域的一次回答，回答得好不好，要拿回领域去验。

这个区分不是咬文嚼字。它决定了你提问的顺序：领域优先的人先问"云市的订单，什么情况下不能再改？"——这是业务事实；软件优先的人先问"订单表要加哪些字段、状态用 int 还是枚举？"——这是实现选择。前者锚定问题，后者锚定一个还没被验证的解。DDD 全书的方法论，就是强制你把提问顺序倒过来。

与下一个概念的关系：领域是无穷复杂的真实世界，代码不可能、也不需要复刻它的全部。你只能挑出对解决当前问题有用的那部分，做一份"够用就好"的抽象——这份抽象就是模型。

1.2模型 Model：对领域的选择性抽象

模型（Model）是对领域的一次选择性抽象：刻意只保留对当前问题有用的概念和规则，扔掉其余——地图不是疆域。

把这层说穿：模型是有目的的简化。"地图不是疆域"——一张地图永远不等于它描绘的那片土地，地图的好坏不看它复刻了多少，而看它为了某个用途保留了对的东西。云市的销售场景关心"这笔订单总额对不对、状态能不能往下走"，所以销售的订单模型只保留 OrderLine（订单项）、Money（金额）、状态机；它不保留商品的详情图集和营销文案——那些对"算钱、推进状态"毫无用处。

由此推出一个让很多人意外的结论：同一个领域，可以、而且应该有多个模型。"商品 Product"这个领域概念，在不同用途下需要不同的抽象——

四个场景说的都是"商品"，但需要的模型截然不同。试图用一个企业级统一的 Product 类同时服务这四种用途，它会长出几十个互相矛盾、半数永远为空的字段——配送场景拿到这个对象，要在一堆营销文案里翻找重量。这个"一个统一模型服务全场景"的旧直觉，正是本书要重置的第一个执念；它的正式答案叫限界上下文，03 章兑现。

与下一个概念的关系：模型既然是人为选择的抽象，就必须有一套办法保证"业务方脑子里的模型"和"代码里实现的模型"是同一个，否则模型就成了工程师的一厢情愿。绑住这两端的那根绳子，叫统一语言。

1.3统一语言 Ubiquitous Language：绑住口语和代码的绳子

统一语言（Ubiquitous Language）是领域专家和工程师共用、并且直接体现在代码里的同一套术语——白话讲就是"嘴上怎么说、代码就怎么写"。

把这层说穿：统一语言是一根双向绑死的绳子。它要求模型里的每个概念，在专家口语和代码里用同一个名字；更关键的是它的诊断作用——当说话和代码对不上时，那是一个信号：模型错了，必须改一端去对齐另一端。语言不是事后给代码贴的注释，它是模型的骨架。Evans 的原话是：术语上的卡壳，往往暴露了模型里一个还没想清楚的概念。

场景走查：一句"确认订单"是怎么断掉的

云市的运营专家在评审会上说："买家点确认后，这笔订单就确认了，确认之后订单项不能再为空，金额也不能再变。"这句话里藏着三个领域事实：有一个叫"确认"的动作；确认是订单状态的一次推进；确认后有些东西被锁死（订单项非空、金额冻结）。现在看两种代码怎么承接这句话：

// 专家说"确认订单"，代码说"把状态字段设成 2"——绳子断了
class OrderStatusService {
    void setStatus(Order order, int status) {
        order.setStatus(status);   // status=2 是什么？只有写的人当时知道
    }
}

// 调用处：业务意图被翻译成了一个魔法数字
statusService.setStatus(order, 2);

// 专家说"确认订单"，代码就叫 confirm()——同一个词
class Order {
    void confirm() {
        // "确认后订单项不能为空"这条领域规则，就长在这个动作里
        ...
    }
}

// 调用处：读代码就是读那句业务原话
order.confirm();

第一段不是"风格差一点"，而是语义丢了。setStatus(2) 这个名字里没有"确认"，没有"确认后订单项非空"，没有"状态只能往前走不能回退"——它把一句有约束的业务陈述，压成了一个谁都能传任意整数的赋值操作。三个月后没人记得 2 是确认还是取消，于是有人传了 setStatus(2) 去跳过支付，状态机就此被绕开。第二段的 order.confirm() 则把那句业务原话原封不动搬进了代码，专家、文档、代码三处用的是同一个词。Vernon 把这条概括为：统一语言活在代码里，也活在团队的嘴里，两处必须是同一套词。

与下一个概念的关系：既然语言要绑死模型，那"这套语言在哪些范围内有效"就成了关键问题。直觉会说"全公司统一一套术语最好"——这恰恰是下一节要拆掉的错觉。

1.4语言的作用域是限界上下文，不是全局

一套统一语言只在一个明确的边界内部保持一致和无歧义；这个边界叫限界上下文（Bounded Context）。追求"全公司一套术语"既不可能也不该追。

把这层说穿：统一语言的"统一"，统一的是一个边界之内，不是全公司。回到 1.2 节那张表——"商品"在目录里是胖展示对象，在销售里是价格冻结的下单快照，在库存里是 SKU+数量。这三个"商品"不是同一个东西穿了三件衣服，它们就是三个不同的概念，各自在自己的边界里有清晰且唯一的含义。把它们硬塞进一个全局 Product，等于把三个互相矛盾的定义压进一个名字，歧义不会消失，只会被埋进字段里。

"客户 Customer"同理：在销售里它是下单的买家 Buyer，在支付里它是付款的付款方 Payer，在营销里它是有等级积分的会员 Member。三个上下文说"客户"时，指的是三种不同的责任和数据。

与下一个概念的关系：到这里，三块地基（领域、模型、语言）和它们的有效边界都立住了。还差一件事——认出一种最常见的"伪富模型"：它长着面向对象的外壳，骨子里却是过程式代码，让前面所有原则形同虚设。

1.5贫血领域模型 Anemic Domain Model：穿着 OO 外衣的过程式代码

贫血领域模型（Anemic Domain Model）：领域对象只剩 getter/setter 的数据，全部业务规则被抽到外部的 Service 里——看着是对象，实质是过程式。

它长什么样：Fowler 给的判据很直接——领域对象里几乎没有行为，只有一堆 getXxx() / setXxx()；所有真正的业务逻辑（校验、状态推进、金额计算）都住在一个名字像 XxxService 的类里，这个 Service 把领域对象当成纯数据袋，取出字段、算一通、再 set 回去。对象有数据没行为，行为有逻辑没数据——这正是过程式编程的形状，只不过套了一层类的外壳。

// 领域对象：只有 getter/setter，零行为——一个数据袋
class Order {
    private OrderStatus status;
    private List<OrderLine> lines;
    private Money total;
    public OrderStatus getStatus()        { return status; }
    public void setStatus(OrderStatus s)  { this.status = s; }
    public List<OrderLine> getLines()     { return lines; }
    public void setLines(List<OrderLine> l){ this.lines = l; }
    public Money getTotal()               { return total; }
    public void setTotal(Money t)         { this.total = t; }
}

// 业务规则全被抽到外面：Order 自己管不住自己的不变量
class OrderService {
    void confirm(Order order) {
        if (order.getLines().isEmpty())            // 规则① 在外面
            throw new IllegalStateException("订单项不能为空");
        if (order.getStatus() != OrderStatus.CREATED) // 规则② 也在外面
            throw new IllegalStateException("状态不允许确认");
        order.setStatus(OrderStatus.CONFIRMED);    // 谁都能绕过这里直接 setStatus
    }
}

// 领域对象：行为和数据在一起，规则被对象自己守住
class Order {
    private OrderStatus status;
    private final List<OrderLine> lines;
    private Money total;

    // "确认订单"是 Order 的能力；规则被关在对象内部，外部绕不过去
    public void confirm() {
        if (lines.isEmpty())                       // 不变量①：确认后订单项非空
            throw new IllegalStateException("订单项不能为空");
        if (status != OrderStatus.CREATED)         // 不变量②：状态机单向推进
            throw new IllegalStateException("只有 CREATED 才能确认");
        this.status = OrderStatus.CONFIRMED;
    }
    // 注意：没有 setStatus —— 状态只能经由 confirm()/pay()/ship() 这些
    //       带规则的动作改变，外部无法直接把它设成任意值
}

两段的差别不在代码量，在谁来保证规则永远成立。贫血版里，Order 暴露了 setStatus()，意味着任何拿到 order 的代码都能 order.setStatus(CONFIRMED) 直接跳过 OrderService.confirm() 里的两条校验——规则只在"大家都走 Service 这条路"的假设下成立，而这个假设迟早被打破。富模型版里，Order 没有 setStatus()，状态只能经由 confirm() 改变，而 confirm() 里焊死了规则，于是"已确认订单不能为空"这条不变量无论谁、从哪里调用，都不可能被违反。