1. 从MVC到DDD的架构演进之路
十年前我刚入行时，MVC架构还是Web开发的金科玉律。记得第一次用Spring MVC完成用户模块时，那种按部就班把代码塞进Controller、Service、Dao层的成就感至今难忘。但随着业务复杂度提升，特别是参与电商中台项目后，我逐渐发现：当订单服务需要同时处理库存、支付、物流等十余个业务域时，传统的分层架构开始显露出力不从心的迹象。
这正是领域驱动设计（DDD）的价值所在。2018年我们重构供应链系统时，首次尝试将采购、仓储、配送等核心业务封装为独立领域，通过限界上下文明确职责边界。当促销系统需要调用库存服务时，不再需要穿透层层Service，而是通过领域服务直接交互。这种以业务语义为核心的建模方式，让系统维护成本降低了40%。
2. MVC架构的经典范式与局限
2.1 标准三层结构解析
典型的MVC分层就像俄罗斯套娃：
code复制HTTP请求 → Controller层（接收参数）
→ Service层（业务逻辑）
→ Dao层（数据库操作）
→ 数据库
以用户注册为例，代码组织方式通常是：
java复制// Controller
@PostMapping("/register")
public Result register(UserDTO dto) {
return userService.register(dto);
}
// Service
public Result register(UserDTO dto) {
User user = convert(dto);
return userDao.save(user);
}
2.2 贫血模型的问题暴露
这种架构最致命的问题是贫血模型（Anemic Domain Model）——业务逻辑全部集中在Service层，而作为数据载体的User类却只有getter/setter：
java复制@Entity
public class User {
@Id
private Long id;
private String username;
// 只有字段定义，没有行为方法
}
当业务规则变复杂时（比如需要校验用户名黑名单、密码强度），所有逻辑都堆积在Service中，最终形成所谓的"上帝服务"。
3. DDD的核心概念与实施路径
3.1 战略设计：划分业务疆域
在电商平台中，我们可以通过事件风暴（Event Storming）识别核心子域：
- 核心域：订单交易、库存管理
- 支撑域：支付网关、物流跟踪
- 通用域：用户中心、权限管理
每个限界上下文用独立的微服务实现，通过防腐层（ACL）隔离外部模型变更的影响。
3.2 战术设计：丰富领域模型
以订单域为例，我们不再使用贫血模型：
java复制public class Order {
private OrderId id;
private List<OrderItem> items;
private Address shippingAddress;
// 领域行为
public void addItem(Product product, int quantity) {
// 校验库存等业务规则
items.add(new OrderItem(product, quantity));
}
// 领域服务
public static class Service {
private OrderRepository repo;
public void createOrder(CreateOrderCommand cmd) {
Order order = new Order(cmd.getItems());
repo.save(order);
publish(new OrderCreatedEvent(order));
}
}
}
4. 架构转型的实操指南
4.1 从数据库驱动到模型驱动
传统开发流程：
code复制设计表结构 → 生成实体类 → 编写CRUD代码
DDD开发流程：
code复制梳理业务场景 → 识别聚合根 → 定义领域事件 → 实现仓储接口
4.2 分层架构的升级方案
推荐采用六边形架构（端口与适配器）：
code复制领域层（核心业务逻辑）
↓
应用层（用例编排）
↙ ↘
基础设施层 用户接口层
(数据库/消息) (REST/RPC)
5. 常见问题与解决方案
5.1 性能优化实践
问题：领域模型频繁加载影响性能
方案：
- 使用CQRS模式分离读写模型
- 对查询场景实现DTO快速映射
java复制@Repository
public interface OrderQueryRepository extends JpaRepository<OrderView, Long> {
@Query("select new OrderView(o.id, o.status) from Order o")
List<OrderView> findSummary();
}
5.2 团队协作建议
-
统一语言（Ubiquitous Language）：
- 在代码中直接使用业务术语（如BacklogItem代替Task）
- 禁止在沟通中使用"那个表"、"那个字段"等技术词汇
-
代码分层规范：
code复制src/
├─ main/
│ ├─ java/
│ │ ├─ domain/ # 领域模型
│ │ ├─ application/ # 应用服务
│ │ ├─ infrastructure # 技术实现
│ ├─ resources/
│ │ ├─ mapping/ # DTO转换配置
6. 架构选型决策树
当面临技术选型时，建议考虑以下因素：
| 评估维度 | MVC适用场景 | DDD适用场景 |
|---|---|---|
| 业务复杂度 | 简单CRUD操作 | 多领域复杂交互 |
| 团队规模 | 5人以下小团队 | 跨职能协作团队 |
| 迭代速度 | 需要快速交付MVP | 长期演进的核心系统 |
| 技术债务 | 短期项目 | 需要持续维护5年以上 |
我在金融支付系统改造中，曾通过渐进式迁移策略完成架构升级：
- 先在风控模块引入领域事件
- 将交易核心重构为聚合根
- 最后用CQRS优化查询性能
这种平滑过渡方式避免了全盘推翻的风险。