一、分层架构的必要性

领域驱动设计（DDD）强调以业务领域为核心构建软件系统，分层架构通过明确的职责划分实现：

1. 关注点分离：隔离业务复杂度与技术实现
2. 可测试性：各层可独立测试验证
3. 可维护性：领域模型演进不影响技术实现
4. 技术无关性：领域层不依赖具体技术栈

二、DDD经典分层架构

1. 用户接口层（Interface Layer）

• 职责：处理用户请求，数据转换与校验
• 组件：
• java

@RestController
@RequiredArgsConstructor
public class OrderController {
    private final OrderAppService orderAppService;
    
    @PostMapping("/orders")
    public ResponseEntity<OrderDTO> 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<OrderItem> 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<OrderItem> 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) {
        // 复杂的定价规则
    }
}

三、框架选型建议

四、分层交互规范

1. 严格单向依赖：

用户接口层 → 应用层 → 领域层
↖               ↖
基础设施层 ←─────┘

2. 跨层调用规则：
3. 禁止基础设施层直接调用领域层
4. 领域对象不直接访问仓储接口
5. 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<OrderSummary> findOrdersByUser(String userId);
}

// 使用JPA Specification实现复杂查询
public class OrderSpecifications {
    public static Specification<OrderEntity> 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

七、常见问题规避

1. 贫血模型反模式：避免仅有getter/setter的领域对象
2. 层渗透问题：禁止基础设施层类型出现在领域层
3. 事务管理：应用层控制事务边界，领域层保持无状态
4. 性能优化：在基础设施层实现查询优化，不影响领域模型

八、演进建议

1. 初期采用标准四层架构
2. 业务复杂后引入六边形架构
3. 高并发场景采用CQRS+Event Sourcing
4. 微服务架构下配合领域事件实现最终一致性

通过遵循DDD分层原则，开发者可以构建出响应业务变化、核心逻辑清晰的高质量系统架构。关键在于保持领域层的纯粹性，通过分层隔离将技术复杂性下沉到基础设施实现中。