边城码志

DDD 落地实践：分层架构与建模示例

Wed, 26 Aug 2026 00:00:00 GMT

前几篇讲完了概念，这篇用一个真实的例子——图书借阅，把 DDD 从战略设计到战术设计、再到代码分层完整串一遍。理解了这一个例子，你就掌握了 DDD 落地的主线。

例子的背景

假设我们要做一个图书馆借阅系统。为了简化，它涉及这样几个业务对象：读者、图书、借阅记录。

如果沿用传统的三层架构，很可能会写成这样：

Controller → Service → DAO（直接用数据库表）

数据库里可能直接有 book 表（含库存）、reader 表、borrow_record 表。业务逻辑（比如"这本书还能不能借"）被散落在 Service 的多个方法里，或者干脆写在 SQL 里。等业务复杂了，就难以维护。

下面我们看看用 DDD 怎么重新组织。

第一步：战略设计——划定边界

对于这个小系统，我们可以先做战略设计的思考：

核心子域：借阅管理。这是系统最核心的价值。
支撑子域：图书管理（藏书、库存），支撑借阅。
通用子域：读者账号、权限，用现成方案即可。

然后划出限界上下文，至少分成两个：

图书上下文：管理图书信息、库存、上架下架。
借阅上下文：管理借阅流程、逾期、归还。

你会发现，"图书"在两个上下文里的含义不同：图书上下文里图书有"库存"，借阅上下文里图书只是"可以被借的东西"。这正是限界上下文存在的意义。

第二步：战术设计——借阅上下文内部建模

聚焦借阅上下文，我们来找实体、值对象和聚合。

实体（有身份、会变化）：

Borrower（借阅者）—— 有 ID。
Borrow（借阅记录）—— 有 ID，状态会从"借出"变到"归还"。

值对象（无身份、不可变）：

BookId（图书 ID）—— 只是对一本具体书的引用。
DueDate（应还日期）—— 一个日期值，没有身份。
BorrowPeriod（借阅周期）—— 包含开始与应还日期。

聚合 + 聚合根：

借阅记录 Borrow 可以作为一个聚合根，它包含 Borrower 和几条 BorrowItem（借了哪几本书），对外只允许通过 Borrow 来操作。这样"一次借阅"这个业务动作的一致性就有保证了。

领域服务：

"借书"这个动作会同时判断图书库存、更新借阅记录，跨越了图书上下文和借阅上下文，所以可以放到领域服务 BorrowingService 里。

第三步：分层架构

DDD 常用的分层是 四层架构，从外到内：

展现层（Controller / 前端 API）
      ↓
应用层（Application Service：编排用例、事务）
      ↓
领域层（Domain：实体、值对象、聚合、领域服务、仓储接口）★核心
      ↓
基础设施层（Infrastructure：仓储实现、数据库、外部调用）

关键在依赖方向：依赖永远指向领域层。也就是说：

领域层不依赖任何技术细节（不 import 数据库、不依赖框架）；
应用层依赖领域层的接口；
基础设施层实现领域层定义的仓储接口。

这样，领域层（也就是业务本身）就变得纯粹、可测试、不受技术绑架。

第四步：看看代码大致长什么样

领域层 —— 值对象 BookId：

public record BookId(String value) {}

领域层 —— 聚合根 Borrow：

public class Borrow {
    private final BorrowId id;
    private final BorrowerId borrowerId;
    private final List<BorrowItem> items;
    private BorrowStatus status;

    // 只有聚合根能改变自己的状态
    public void returnBooks() {
        if (this.status == BorrowStatus.RETURNED) {
            throw new IllegalStateException("already returned");
        }
        this.status = BorrowStatus.RETURNED;
    }
}

领域层 —— 仓储接口：

public interface BorrowRepository {
    Borrow findById(BorrowId id);
    void save(Borrow borrow);
}

基础设施层 —— 仓储实现：

public class JpaBorrowRepository implements BorrowRepository {
    @Override
    public Borrow findById(BorrowId id) {
        // 用 JPA / MyBatis 等具体技术实现
        return ...;
    }
}

可以看到，领域层代码里没有任何数据库或框架的影子，它只表达业务。这正是 DDD 想达到的效果。

落地时的常见误区

最后，整理几个我踩过/看到过的坑：

不要为了 DDD 而 DDD：业务简单时强行分层只会增加复杂度。DDD 的价值在复杂业务。
不要把领域层写脏：最常见的失败是领域层里出现了 @Entity、Repository 的实现、甚至 SQL，导致领域层被技术绑架。
应用层要"薄"：应用层只做编排和事务，真正的业务规则要下沉到领域层。应用层胖了，就是"贫血模型"回潮。
从小处开始：先在一个上下文试点，别指望一步到位。

总结

这一系列四篇笔记，完整走了一遍 DDD：

认识 DDD：以业务领域为核心的方法论。
战略设计：子域划分、限界上下文、统一语言。
战术设计：实体、值对象、聚合、仓储、领域服务。
落地实践：分层架构 + 一个完整建模示例。

如果你和我一样，正在用 DDD 的项目里摸索，建议从战略设计的限界上下文和战术设计的聚合这两个概念抓起——它们是最能体现 DDD 价值、也最容易被忽视的地方。

祝我们都能在 DDD 的路上少踩点坑。😄

DDD 战术设计：实体、值对象与聚合

Mon, 24 Aug 2026 00:00:00 GMT

战略设计决定了系统的骨架，战术设计则决定了骨架内部的肌肉。这篇笔记用尽量通俗的方式，讲清楚战术设计中几个最核心的概念。

实体（Entity）：有身份的"东西"

实体是有唯一标识、且会变化的对象。

类比：一个人。哪怕他改了名、换了工作、搬了家，他还是"这个人"——因为他的身份证号不变。

对应到代码，实体的关键是：

有唯一标识（ID）；
有生命周期，状态会随业务变化；
身份稳定，ID 是判断"是不是同一个"的标准。

比如订单、用户、账户，都是典型的实体。两个订单即使内容完全一样，也是两个不同的对象，因为它们的 ID 不同。

值对象（Value Object）：只描述"值"的东西

值对象是没有独立身份、完全由属性值决定的对象。

类比：一个地址。北京市朝阳区某某路 1 号——这就是它本身，你不需要给这个地址一个"ID"。换了个地址，就是换了个新对象。

值对象的特征：

没有身份，两个内容相同的值对象就是"相等"的；
不可变，值对象创建后不应被修改；
常用来封装一些概念，如地址、金额、坐标、时间段。

比如"金额"可以做成值对象，包含 金额数值 和 币种，而不是裸用一个 double。这样能避免"不同币种乱相加"这类低级错误。

实体 vs 值对象

判断一个对象该做成实体还是值对象，就看它有没有独立身份、是否可共享复用：

判断维度	实体	值对象
是否有 ID	有	没有
是否可变	会变	不可变
是否被共享	独立拥有	可被共享引用
例子	订单、用户	金额、地址

聚合（Aggregate）：一组对象的边界

聚合是 DDD 战术设计里最重要的概念。它把一组关联紧密的对象绑定在一起，由一个聚合根统一对外提供访问。

类比：一辆汽车。发动机、变速箱、轮子是它的部件，但你要启动汽车，只需要操作"启动按钮"（聚合根），不需要直接去操作每一个零件。

聚合的三个要点：

一个聚合根：对外唯一的入口，只有通过聚合根才能修改聚合内部的对象；
一致性边界：聚合内部的数据变更必须保持业务上的一致性；
数据访问最小化：外部不能绕过聚合根直接操作内部对象。

为什么需要聚合？

聚合是为了解决事务一致性和并发控制的复杂度。如果不设聚合，所有对象之间都能随意互相引用、互相修改，数据一致性就完全失控了。

聚合有一个重要设计原则：优先用小聚合。聚合越小，事务范围越小，并发冲突越少，系统扩展性越好。不要贪大。

仓储（Repository）：数据访问的抽象

仓储负责在领域模型和持久化存储之间做桥接。它让领域层不需要关心数据到底存的是数据库、还是 Redis、还是文件。

类比：仓储就像书架。书架帮你把书放好、按需取回，但你不用关心书是放在书架的哪一格。

仓储的要点：

面向聚合根设计，一个聚合对应一个仓储；
只暴露领域需要的接口（如 findById、save），把数据库细节藏在实现里；
让上层可以方便地替换持久化方案。

领域服务（Domain Service）：放不下实体里的业务逻辑

有些业务逻辑不属于某一个实体，而是跨多个实体/聚合协作。这时就用领域服务来承载。

类比：一次转账。转账涉及转出账户和转入账户两个对象，它既不属于转出账户，也不属于转入账户，于是把它放在一个"转账服务"里。

判断是不是领域服务的标准：这个操作是否不适合放在任何一个实体/值对象里。如果可以放，就不要硬造服务，否则会退化成"贫血模型"。

战术设计的小总结

战术设计提供了一套建模工具箱：

概念	作用
实体	有身份的、会变化的核心对象
值对象	无身份、不可变、按值相等的对象
聚合	由聚合根统领的一致性边界
仓储	聚合与持久化的桥接
领域服务	承载跨对象的业务逻辑

这几个概念组合起来，就能把某个限界上下文内部建模得清晰、内聚。下一篇笔记，我会用一个实际的业务例子，把这些概念完整串起来，看看 DDD 到底怎么落地。

下一篇：DDD 落地实践：分层架构与建模示例

DDD 战略设计：领域、子域与限界上下文

Sat, 22 Aug 2026 00:00:00 GMT

上一篇笔记讲了 DDD 的整体认识，这篇深入到 DDD 的第一个层次——战略设计。它是决定整个系统边界的关键一步。

什么是领域（Domain）

"领域"就是软件要解决的问题所在的业务范围。比如：

一个电商系统，领域是"在线交易"；
一个医院挂号系统，领域是"医疗服务"；
一个物流系统，领域是"货物运输"。

领域并不是一个抽象的大词，它是由一系列业务活动、规则、概念组成的。开发这个系统的人，本质上是在用代码重新描述这个领域。

子域（Subdomain）：把领域拆小

一个真实的业务领域往往非常大。比如"电商"这个领域，包含商品、库存、订单、支付、营销、物流、会员…… 直接对整个领域建模会非常困难。所以战略设计的第一步，就是把大领域拆分成若干子域（Subdomain）。

子域一般分成三类：

类型	特点	例子（电商）
核心子域	公司最有竞争力、最不能外包的部分	订单、交易
支撑子域	重要但非核心，可自研也可外包	库存、营销
通用子域	没有业务特性，行业通用，通常用现成方案	权限、日志、认证

拆分时最重要的一点是：资源要优先投给核心子域。核心子域是最值得投入精力的地方，通用子域直接用成熟方案（比如用现成的鉴权框架），没必要自己造轮子。

限界上下文（Bounded Context）：真正的边界

如果说"子域"是业务视角的划分，那么"限界上下文"就是技术/实现视角的边界划分。

限界上下文是 DDD 里我认为最核心的概念。它的含义是：

一个限界上下文就是一个明确的边界，在这个边界内，模型、术语、规则是一致的。

回到之前"订单状态"的例子：电商团队的 订单 和物流团队的 订单，其实是两个不同限界上下文里的不同模型。

在交易上下文里，订单关注"是否支付、是否超时、是否关闭"；
在履约上下文里，订单关注"是否拣货、是否出库、是否签收"。

它们都叫"订单"，但关心的事实和规则完全不同。如果硬要用一个"大而全"的订单模型去覆盖所有场景，必然导致混乱。

为什么需要限界上下文？

核心原因：一个统一的模型无法满足所有场景。

不同场景对同一概念的需求是矛盾的。比如"商品"在销售上下文里需要"价格、促销"属性，在仓储上下文里需要"库存量、存放货架"属性。强行统一会让模型臃肿，也让每个团队都要迁就别人。

所以限界上下文的做法是：各自维护自己的模型，通过明确的上下文边界隔离复杂度。

上下文之间的集成

既然拆成了多个上下文，它们之间就需要协作。DDD 提供了一些**上下文映射模式（Context Mapping）**来定义协作关系，比如：

防腐层（Anti-Corruption Layer）：隔离外部系统对自身模型的污染。
共享内核（Shared Kernel）：两个上下文共享一小部分稳定模型。
开放主机服务（Open Host Service）：通过公开 API 对外提供服务。

这些模式里，日常用得最多、也最实用的就是防腐层——当你的系统要对接一个模型很混乱的旧系统或第三方系统时，防腐层能把外部复杂性挡在边界之外。

统一语言（Ubiquitous Language）

战略设计里还有一个贯穿始终的概念——统一语言。

它要求业务人员和开发人员在同一个限界上下文内，使用完全一致的术语。业务说"下单"、"退款"、"驳回"，代码里就应该是 placeOrder、refund、reject，而不是 createOrder、payRollback、updateStatusToXxx。

统一语言的价值在于：当业务人员能读懂你的领域模型，代码和业务就真正对齐了。这也要求我们模型命名要贴近业务语言，而不是贴近数据库表名。

小结

战略设计回答了"系统边界在哪"：

用子域从业务视角拆分大领域，并识别出核心子域优先投入。
用限界上下文从实现视角划定模型边界，隔离复杂度。
用统一语言保证业务与代码术语一致。

下一步，进入 DDD 的第二个层次——战术设计，看看在某个上下文内部，实体、值对象、聚合这些战术概念怎么用。

下一篇：DDD 战术设计：实体、值对象与聚合

什么是领域驱动设计（DDD）？

Thu, 20 Aug 2026 00:00:00 GMT

我最近在用一个采用 DDD 思想的项目，但一直没完全理解它。这篇是我的学习笔记，希望能帮助同样刚接触 DDD 的朋友建立起整体的认识。

为什么会出现 DDD？

传统的分层架构（Controller → Service → DAO）在业务简单的系统里非常高效。但随着业务变得越来越复杂，很多团队发现一个普遍的问题：

技术代码写得越来越熟练，但业务逻辑却越来越混乱。

举个典型的例子：一个"订单"状态。在代码里，订单可能有 status 字段，电商团队写 status = 2 表示"已支付"，物流团队写 status = "paid"，报表团队又有一套 orderState。同一个业务概念，在不同系统里有着不同的表达。业务方说"改一下订单状态"，你根本不知道要改哪一行代码。

DDD（Domain-Driven Design，领域驱动设计）就是针对这类问题提出的方法论。它的核心思想是：

软件系统的复杂性和核心价值都在于业务领域本身，而不是技术实现。

因此，软件开发应该以"领域"为核心，让技术为业务服务，而不是让业务去迁就技术。

DDD 关注什么

DDD 大致可以分成两个层次：

层次	关注点	回答的问题
战略设计	系统边界、上下文划分	整个系统怎么拆？哪些是核心？
战术设计	代码内部的建模	一个模块内部的类怎么设计？

战略设计回答"拆成几块、边界在哪"，战术设计回答"每一块里面长什么样"。两者是递进关系：先定边界，再细化内部。

几个最常见的误解

接触 DDD 时，很容易陷入下面几个误区：

误解一：DDD 就是"领域模型 + 贫血/充血模型"

很多人一听说 DDD 就以为是"把业务逻辑塞进实体类里"。其实这只是战术设计里的一个细节。DDD 最重要的贡献是战略设计——教会大家如何划分业务边界，而这部分经常被忽略。

误解二：DDD 只适合大型项目

DDD 确实在复杂系统里收益最大，但这不意味着小项目不能用。关键在于建模思维：先把业务领域想清楚，再写代码。这个习惯对任何规模的项目都有价值。

误解三：DDD 是一种框架

DDD 不是框架，也不是某个库。它是一种思考和建模的方法论。你完全可以在 Spring Boot、Go、Node.js 里落地 DDD，也可以用手写代码的方式落地。

DDD 的核心价值

我觉得 DDD 最大的价值有三个：

统一语言：让业务人员和开发人员使用同一套术语交流，避免"鸡同鸭讲"。
清晰的边界：通过限界上下文划分系统边界，控制复杂度。
业务为核心：让软件模型贴近真实业务，业务变了代码知道怎么改。

小结

这篇文章只是 DDD 的"地图"，先建立整体印象。接下来的几篇笔记我会分别展开：

先从最重要的战略设计开始看吧，它决定了整个系统的骨架。