一、从最简单的 MVC 开始

我的项目最初只有三层。

Controller 接 HTTP 请求。Service 写业务逻辑，Mapper 读写数据库——标准 Spring MVC，没有任何过度设计，跑了两年没出大问题。

接下来业务开始增长。个业务领域、很多跨模块调用、无法独立测试的业务逻辑。某天我需要修改某个业务规则。打开对应的 Controller，顺着调用链往下追。发现一次数据库操作要穿越三个中间层：

controller/AchievementController → service/business/AchievementUnlockService
<-- 业务服务层    → service/impl/UserAchievementServiceImpl
<-- MyBatis-Plus ServiceImpl      → repository/UserAchievementMapper
<-- 数据库

这就是项目里的三跳依赖链。改一个业务规则，需要同时理解四个文件的职责。而且这条链在全部 个业务领域里都存在。

这篇文章记录的，是我在 天内用 个提交把它改造成 DDD 架构的完整过程。能在 天内完成而没有失控，关键靠两件事：Claude Code Superpowers 技能库提供了工程纪律。OpenSpec Comet 工作流提供了过程管控。

下面是完整过程。

二、这条链是怎么长出来的

至于项目初期，合理的起点

我的项目是一个移动端应用的后端服务。初期采用标准的 Spring MVC 分层：

server-api/
├── controller/ # HTTP 接口层
├── service/ # 业务逻辑层
├── service/impl/ # 业务逻辑层
├── service/business/ # 复杂业务编排
├── repository/ # Mapper 接口
└── ...common/
├── entity/ # MyBatis-Plus 实体
├── param/ # 请求/响应 DTO
├── mapper/ # MapStruct 转换器
└── enums/ # 枚举

这个结构在项目初期完全够用。怎么说呢，Controller 调用 Service。Service 调用 Mapper，逻辑清晰。按理说，

至于业务增长后。边界开始模糊

• 痛点 ：职责边界不清
• service/business/ 的类越来越复杂。 话说回来，有些 Service 只是简单地传递调用。有些则混合了 IO 操作、业务规则、DTO 组装——三种性质完全不同的代码住在同一个类里没有人能说清楚它们的边界在哪里。
• 痛点 ：横向依赖蔓延
• 模块间调用随意：A 模块需要感知 B 模块状态。B 模块需要调用 C 模块，而 C 模块又依赖使用者信息。由于大家都在 service/ 包里跨领域调用直接 @Autowired,成了一张没有显式边界的依赖网。新工程师看着依赖图会问：“这里真的可以直接调那里吗？话说回来，”——没有规则告诉他。
• 痛点 ：common 模块成了垃圾桶
• • Mysql-Plus 实体
  • HTTP 请求/响应 DTO
  • 第三方 API 模型
• 结果就是 Controller 直接把持久化实体返回给前端；业务 Service 直接接收 HTTP 请求 DTO；数据库字段变动会直接影响 API 响应——层与层之间没有任何缓冲。
• 痛点 ：无法独立测试
• 想对主要业务规则写单元测试？你需要 Mock UserAchievementServiceImpl，它继承 MyBatis-Plus 的 ServiceImpl。后者依赖 BaseMapper，再由 BaseMapper 依赖数据库连接…，最终写不了纯业务逻辑单元测试，只能写集成测试。

三、DDD 能解决什么

I won't dive into DDD ory here. Just focus on three concepts directly relevant to this migration:

Bounded Context : 把程序拆成若干个边界清晰子程序。每个子程序内部自治，对外通过明确定义接口通信。在我的项目里,achievement,auth_user。travel 等 多个领域各自是一个 Bounded Context..

四层结构:

interfaces →
application →
domain →
infrastructure

端口与适配器:: Application 层只定义 “我需要什么”，Infrastructure 层负责 “怎么实现”。business logic 对数据库HTTP消息队列完全无感知。

 这些概念正好对应上面那三个痛点：Context 划分解决横向依赖问题。

四层结构解决职责混乱问题，端口与适配器解决可测试性问题。