microwind/ai-skills/ddd-vs-mvc

┌──────────────────┐
│      View        │  视图展示（JSP、前端页面、返回 JSON）
└────────┬─────────┘
         ▲
         │
┌────────┴─────────┐
│   Controller     │  接收请求、编排业务、返回响应
│                  │  通常辅以 Service 实现业务逻辑
└────────┬─────────┘
         │
┌────────┴─────────┐
│      Model       │  数据库模型（ORM 实体 / DO）
└──────────────────┘

src/
  ├── controller/    ← 接口入口
  ├── service/       ← 业务逻辑（但很容易变成"数据搬运工 + if/else"）
  ├── model/         ← 数据库实体
  ├── dao/           ← 数据访问
  └── util/

// ❌ MVC 风格：一看就是"技术语言"
@RestController
public class OrderController {
    @PostMapping("/orders/{id}/status")
    public void updateStatus(@PathVariable Long id, @RequestBody Map<String, Object> body) {
        Order order = orderDao.getById(id);
        order.setStatus((Integer) body.get("status"));
        orderDao.update(order);
    }
}

// ❌ 贫血模型 + 胖 Service
public class Order {  // 只有 getter/setter
    private Long id;
    private Integer status;
}
 
public class OrderService {
    public void pay(Long orderId) {
        Order o = dao.get(orderId);
        if (o.getStatus() != 0) throw new RuntimeException("状态错误");
        // ...大量业务规则堆在这里
        o.setStatus(1);
        dao.update(o);
    }
    public void ship(Long orderId) { /* ... */ }
    public void cancel(Long orderId) { /* ... */ }
    // ... 50 个方法
}

MVC 只规范"一个应用内部怎么分层"，不解决：
  ✗ 业务该拆几个服务？
  ✗ 服务之间的边界在哪？
  ✗ 团队怎么分工？
  ✗ 哪些是核心业务，哪些是通用能力？
 
→ 全靠技术负责人"看经验拍脑袋"
→ 大团队协作时容易职责不清、分工不明

MVC 是"战术"问题：代码怎么组织
DDD 既是"战略"问题（业务如何划分）
       也是"战术"问题（如何建模）
 
DDD 分层架构 ⊇ MVC + 更细的分层 + 领域建模 + 边界划分

✅ 使用 MVC（或更轻量）：
  ▸ 业务简单：CRUD 为主，规则少
  ▸ 项目小：个人项目、内部工具
  ▸ 时效紧：MVP、POC、原型验证
  ▸ 团队小：1~3 人
  ▸ 典型：管理后台、数据报表、简单 API
 
✅ 使用 DDD：
  ▸ 业务复杂：规则多、流程长、分支多
  ▸ 长期演进：核心域，未来会持续迭代
  ▸ 多团队协作：需要明确边界分工
  ▸ 需要领域模型：业务知识值得沉淀
  ▸ 典型：SaaS 平台、B 端业务系统、金融系统、电商核心
 
❌ 常见误区：
  ▸ 为了"DDD 而 DDD"：把简单 CRUD 套上繁重分层，反而拖累开发效率
  ▸ "全盘 DDD 一把梭"：即使同一公司，通用域用 MVC、核心域用 DDD 是常见做法
  ▸ 把 DDD 当"银弹"：业务本身的复杂度靠设计规避不了，深刻理解业务才是关键

Phase 1  MVC：快速验证业务可行性
          ↓
Phase 2  半 DDD：保留 MVC 骨架，在核心模块引入领域模型与聚合
          ↓
Phase 3  完整 DDD：核心域按限界上下文拆微服务，应用 [分层架构](../layered-architecture/)
          ↓
Phase 4  持续演进：根据业务理解加深，不断重构领域模型