DDD落地指南：如何用Spring Modulith重构老旧单体系统

DDD落地指南：如何用Spring Modulith重构老旧单体系统

---

---

一、当单体系统变成“代码毛线球”

接手一个五年历史的订单系统时，我仿佛看到一团纠缠的毛线：用户服务里藏着库存逻辑，支付模块调用了物流接口，改个运费计算要翻20个类。这就像老城区改造——居民楼里开工厂，菜市场楼上住人，想修条水管得挖穿半条街。

传统分包方式已失效：

// 典型混乱结构（像把所有家具堆进一个房间）
com.company.order
├── OrderController.java   // 控制层
├── UserService.java       // 业务层（却处理库存？）
├── PaymentUtil.java       // 工具类（含物流校验？）
└── entity
    ├── Order.java         // 订单实体
    └── Product.java       // 商品实体（放订单包？）

每次新需求都像在危房上加盖楼层，稍有不慎全盘崩溃。我们需要用DDD思想重新规划，而Spring Modulith就是那把手术刀。

---

二、Spring Modulith：城市功能区划分师

Spring Modulith的核心思想是模块即城市功能区：

• 订单模块 = 商业区
• 库存模块 = 物流园
• 用户模块 = 住宅区

1. 模块化改造第一步：划定边界

// 新结构（像城市规划图）
src/main/java
├── order                  // 订单核心区（独立自治）
│   ├── Order.java         // 领域实体
│   ├── OrderService.java  // 领域服务
│   └── OrderEvents.java   // 领域事件
├── inventory              // 库存保税区
│   ├── Stock.java
│   └── StockService.java
└── user                   // 用户生活圈
    ├── User.java
    └── UserService.java

// 在application.properties声明模块（颁发区域牌照）
spring.modulith.modules
  order.base-package=com.example.order
  inventory.base-package=com.example.inventory
  user.base-package=com.example.user

2. 跨模块通信：修高架桥不拆墙

// 订单模块触发事件（像商业区发布需求）
@Service
public class OrderService {
   
    private final ApplicationEventPublisher events;
    
    public void completeOrder(Order order)