一、分层架构的必要性
领域驱动设计（DDD）强调以业务领域为核心构建软件系统，分层架构通过明确的职责划分实现：
- 关注点分离：隔离业务复杂度与技术实现
- 可测试性：各层可独立测试验证
- 可维护性：领域模型演进不影响技术实现
- 技术无关性：领域层不依赖具体技术栈
二、DDD经典分层架构
1. 用户接口层（Interface Layer）
- 职责：处理用户请求，数据转换与校验
- 组件：
- java
@RestController
@RequiredArgsConstructor
public class OrderController {
private final OrderAppService orderAppService;
@PostMapping("/orders")
public ResponseEntity createOrder(@Valid @RequestBody CreateOrderRequest request) {
OrderDTO order = orderAppService.createOrder(request);
return ResponseEntity.created(URI.create("/orders/"+order.id())).body(order);
}
} 2. 应用层（Application Layer）
- 职责：协调领域对象完成业务用例
- 特点：
- 事务边界控制
- 无业务逻辑，仅流程编排
- java
@Service
@RequiredArgsConstructor
public class OrderAppService {
private final OrderRepository orderRepository;
private final DomainEventPublisher eventPublisher;
@Transactional
public OrderDTO createOrder(CreateOrderRequest request) {
Order order = OrderFactory.create(request);
orderRepository.save(order);
eventPublisher.publish(new OrderCreatedEvent(order));
return OrderAssembler.toDTO(order);
}
}3. 领域层（Domain Layer）
- 核心：包含业务实体、值对象、领域服务
- 设计要点：
- 充血模型：行为与数据共存
- 保持技术无关性
- java
public class Order {
private OrderId id;
private List items;
private OrderStatus status;
public void addItem(Product product, int quantity) {
items.add(new OrderItem(product, quantity));
recalculateTotal();
}
private void recalculateTotal() {
// 业务计算逻辑
}
}
@DomainService
public class PricingService {
public Money calculateDiscount(Order order) {
// 复杂的定价规则
}
} 4. 基础设施层（Infrastructure Layer）
- 职责：实现技术细节
- 典型组件：
- java
public class Order {
private OrderId id;
private List items;
private OrderStatus status;
public void addItem(Product product, int quantity) {
items.add(new OrderItem(product, quantity));
recalculateTotal();
}
private void recalculateTotal() {
// 业务计算逻辑
}
}
@DomainService
public class PricingService {
public Money calculateDiscount(Order order) {
// 复杂的定价规则
}
} 三、框架选型建议
层级 | 推荐框架 | 作用说明 |
用户接口层 | Spring MVC/WebFlux | 请求处理与响应格式化 |
应用层 | Spring Core | 事务管理与依赖注入 |
领域层 | 无框架依赖 | 保持领域纯净性 |
基础设施层 | JPA/MyBatis, Spring Data | 持久化实现 |
MapStruct | DTO转换 | |
Axon Framework | 事件溯源支持 |
四、分层交互规范
- 严格单向依赖：
用户接口层 → 应用层 → 领域层
↖ ↖
基础设施层 ←─────┘- 跨层调用规则：
- 禁止基础设施层直接调用领域层
- 领域对象不直接访问仓储接口
- DTO转换应在应用层完成
五、关键实践指南
1. 聚合根设计
java
public class Order {
// 对外暴露行为方法而非setter
public void cancel() {
verifyCancellable();
this.status = OrderStatus.CANCELLED;
registerDomainEvent(new OrderCancelledEvent(this));
}
private void verifyCancellable() {
if (status != OrderStatus.CREATED) {
throw new IllegalOrderStateException();
}
}
}2. CQRS实现
java
// 命令端
public interface OrderCommandRepository {
void save(Order order);
}
// 查询端
public interface OrderQueryRepository {
List findOrdersByUser(String userId);
}
// 使用JPA Specification实现复杂查询
public class OrderSpecifications {
public static Specification statusIs(OrderStatus status) {
return (root, query, cb) -> cb.equal(root.get("status"), status);
}
} 3. 领域事件处理
java
复制
// 事件定义
public class OrderPaidEvent extends DomainEvent {
private String orderId;
private LocalDateTime paidTime;
}
// 事件处理器
@Component
public class OrderPaidEventHandler {
@EventListener
public void handle(OrderPaidEvent event) {
// 更新物流状态等后续处理
}
}六、项目结构示例
复制
src/main/java
├── application
│ ├── dto
│ ├── service
│ └── assembler
├── domain
│ ├── model
│ ├── service
│ ├── event
│ └── repository
├── interfaces
│ ├── rest
│ ├── rpc
│ └── web
└── infrastructure
├── dao
├── config
└── external七、常见问题规避
- 贫血模型反模式：避免仅有getter/setter的领域对象
- 层渗透问题：禁止基础设施层类型出现在领域层
- 事务管理：应用层控制事务边界，领域层保持无状态
- 性能优化：在基础设施层实现查询优化，不影响领域模型
八、演进建议
- 初期采用标准四层架构
- 业务复杂后引入六边形架构
- 高并发场景采用CQRS+Event Sourcing
- 微服务架构下配合领域事件实现最终一致性
通过遵循DDD分层原则，开发者可以构建出响应业务变化、核心逻辑清晰的高质量系统架构。关键在于保持领域层的纯粹性，通过分层隔离将技术复杂性下沉到基础设施实现中。