战略设计：把建模精力投到哪一块

本章用贯穿全书的「云市」电商交易平台作示例。云市要做的事很多：商品展示、下单、库存、配送、收款、退款、登录、发通知。把它们一股脑当成"一个电商系统"去建模，是工程师最常见的起手式，也是战略设计要纠正的第一个直觉。战略设计的第一刀，就是把这一坨业务切成块。

2.1子域 Subdomain：领域是由子问题拼成的

子域（Subdomain）：领域里相对独立的一块子问题。一个领域不是单一问题，而是一组关注点不同的子问题的集合。

底层机制（比定义深一层）：子域属于问题空间——它描述的是"业务上客观存在的一块子问题"，而不是你打算用哪个系统、哪张表去实现它。识别子域靠的是业务语言的断裂：当人们换一套词汇、换一批关心的指标、换一群对接的人时，你多半跨过了一条子域边界。在云市，"加购物车、下单、订单状态"是一套语言，"安全库存、预留、仓位拣货"是另一套语言，"对账、退款、风控"又是一套。三套语言之间的人会争吵——这恰恰是边界存在的信号。

把云市初步切块，得到这样一组子域：

注意这一步还没有谈"建几个微服务""设计几张表"。子域是对问题的认识，不是对方案的承诺——这条分界是 2.3 节的主题，先放着。这里只确立一点：云市不是一个问题，是六七块关注点迥异的子问题。

与下一节的关系：切出六七块只是第一步。真正决定胜负的是下一个问题——这几块里，哪一块才是云市赖以活命、对手抄不走的？这就要给子域分级。

2.2核心域 / 支撑域 / 通用域：价值是非线性的

三类子域：核心域（Core Domain）是竞争差异所在、对手抄不走；支撑域（Supporting Subdomain）是业务需要但不构成差异；通用域（Generic Subdomain）是人人都要、市面有现成方案。

三类的判别标准（领域真名）：

• 核心域 Core Domain：这块做得比对手好，企业就赢；做砸了就输。它是差异化的来源，外面买不到对等品，因为买得到的对手也都有了，就不叫差异。判据："如果这块外包给随便一家公司做成行业平均水平，我们还有竞争力吗？"——答"没有"的，就是核心域。
• 支撑域 Supporting Subdomain：业务跑起来确实需要它，但它本身不构成差异，市面上又没有刚好贴合的现成品（业务规则比较特有）。判据："少了它业务转不动，但它做到行业平均就够，没人会因为它选我们。"
• 通用域 Generic Subdomain：很多企业都要、且需求高度标准化，市面有成熟方案。判据："这问题几十年前就被解决了，我们自研只是在重新发明轮子。"

场景走查：给云市的子域分级

把 2.1 切出的子域逐块过判据：

这里要把 2.1 的"下单交易"进一步拆开看：订单状态机是支撑性的（行业平均就够），但定价与撮合是核心。同一句"下单"，里面既有支撑域也有核心域——分级看的是价值，不是模块名。这正是战略设计要逼出的精细：不要因为"它们都叫订单系统"就一视同仁。

"价值非线性"到底什么意思：把投入画成横轴、回报画成纵轴，核心域那条曲线很陡——每多投一分精力（更准的模型、更深的领域规则、更紧的反馈闭环），回报显著上扬；而通用域那条线几乎是平的，甚至向下：你自研支付，投入再多也只是逼近一个早就被商品化的能力，省下的钱比不过 SaaS，还要养一支团队填合规与风控的坑。下一节的"投资拨盘"把这条非线性曲线落成具体的投资动作。

与下一节的关系：分级回答了"哪块值钱"。但分级本身不会自动变成行动。需要一个把"价值差异"翻译成"投资动作"的工具——投资拨盘。

2.3问题空间 vs 解空间：发现 vs 设计

子域属于问题空间（被发现）；限界上下文属于解空间（被设计）。前者是业务客观长成的样子，后者是你为应对它而划的方案边界——二者只力求一一对应，但不天然相等。

两个空间的精确分工：

• 问题空间 = 子域。它是被发现的：你去和业务方聊、听他们换词、看指标和争吵，把领域里客观存在的子问题识别出来。你无法发明子域——云市需不需要"履约"这件事，由生意本身决定，不由架构师决定。
• 解空间 = 限界上下文（Bounded Context，03 章详解）。它是被设计的：在确认了子域之后，你主动划出一道道模型与语言的边界，在每道边界内让一套统一语言（01 章）保持一致。边界画在哪、画几道，是工程决策。

为什么是"力求 1:1"而不是"必然 1:1"：理想状态是一个子域对应一个限界上下文，干净利落。但现实里会偏离——有时遗留系统把两个子域焊在一个上下文里（一个大系统同时管订单和库存），有时一个子域因为团队或技术原因被拆成两个上下文。1:1 是设计目标，不是事实保证；偏离 1:1 不一定是错，但每一次偏离都该是有意识的取舍，而不是稀里糊涂长出来的。03 章会把这层映射关系彻底讲透，这里先把"两个空间"这根桩打牢。

与下一节的关系：分清了"业务有哪几块（问题空间）"和"我打算怎么应对（解空间）"，最后一个问题是钱和精力——每一块，我到底是自研、是买、还是随便糊一个 CRUD？这是投资拨盘。

2.4投资拨盘：核心自研 / 通用买 / 支撑 CRUD

投资拨盘：按子域分级配不同的实现强度——核心域上全套 DDD 自研，通用域买或接 SaaS，支撑域用 CRUD 或事务脚本。把最贵的精力只压在核心域。

三个档位（与三类子域对齐）：

• 核心域 → 全套 DDD 自研。这里值得上限界上下文、聚合、值对象、领域服务（05–06 章）这套重武器，因为模型的精细度直接转化成竞争力。云市的智能定价 & 撮合就该这么对待：把领域规则深深刻进模型，而不是散在一堆 if-else 里。
• 通用域 → 买或接 SaaS。支付接现成支付网关、认证接身份服务、通知接消息平台。自研只会重复造轮子并背上长期维护负担。这里的工程重点不是建模，而是集成——通过防腐层（Anticorruption Layer, ACL，03 章）把外部模型挡在核心之外。
• 支撑域 → CRUD 或事务脚本。订单状态流转、库存增减这类，业务规则不算复杂、又不构成差异，用直白的事务脚本（Transaction Script，把一个用例的逻辑写成一段过程式代码）或常规 CRUD 即可。在这里硬上全套聚合，是用屠龙刀切菜。

核心论点："均匀地用 DDD 最贵"：全套 DDD 是有成本的——更长的建模时间、更高的认知门槛、更多的间接层。把它均匀地铺到每个子域，等于在支撑域和通用域上付了核心域的价，却拿不到核心域的回报。真正划算的策略是差异化投入：把这套重武器的成本，只花在那条回报陡峭的核心域曲线上。这也呼应了一条贯穿全书的判断——限界上下文不等于微服务，模块化单体优先；不要因为"用了 DDD"就给每块子域都配一套独立部署的重型基础设施。

这就是图 2.1 里那条非线性曲线的工程落地：横轴是投入档位（CRUD → 买 → 全套自研），纵轴是回报。核心域处在曲线陡峭段，加投有显著回报；通用域处在平坦段，加投几乎不回本、自研甚至为负。投资拨盘就是让你显式地为每个子域选一个档位，而不是默认全开最大档。

场景走查：给云市三块定投资动作

把分级直接翻译成实现决策，并写成应用服务里的一句调用编排（仅示意"谁自研、谁集成"，不是完整实现）：

// 应用服务：只编排，不写业务规则（业务规则在各自的档位里）
public class PlaceOrderApplicationService {

    private final PricingService pricing;        // 核心域：全套 DDD 自研，规则刻进模型
    private final OrderRepository orderRepository;// 支撑域：常规仓储 + 直白事务脚本
    private final PaymentGateway paymentGateway;  // 通用域：接 SaaS，ACL 挡在外面

    public OrderId placeOrder(BuyerId buyerId, List<CartLine> cart) {
        // ① 核心域：定价撮合，云市的差异化能力，深建模
        Money total = pricing.quote(buyerId, cart);

        // ② 支撑域：装配并持久化订单，事务脚本即可，不必过度建模
        Order order = Order.place(buyerId, cart, total);
        orderRepository.add(order);

        // ③ 通用域：收款交给外部网关，本系统只发起、不重造支付
        paymentGateway.charge(order.id(), total);

        return order.id();
    }
}

三行调用，三个档位：PricingService 是自研的核心域重头戏；OrderRepository + Order.place(...) 是支撑域的直白持久化；PaymentGateway 是通用域的外部集成。同一个用例里并存三种投入强度，这正是投资拨盘的样子——不是"整个系统用不用 DDD"，而是"每一块各拨到哪一档"。

本章收口：战略设计回答的是"把精力投到哪"——先用子域把领域切块（2.1），按核心 / 支撑 / 通用给价值分级（2.2），分清问题空间与解空间（2.3），再用投资拨盘把价值差异落成投入差异（2.4）。下一章接住 2.3 埋的桩，专讲解空间里那道被设计的边界：限界上下文——它是语义边界，不是微服务边界，也正是"同一个词在不同上下文里是不同的类"的根源。