ddd-microservices

适用场景

当用户希望执行以下操作时，使用此技能：

• 使用 DDD 定义微服务边界（限界上下文、聚合、领域事件）
• 设计服务间契约和事件驱动通信
• 实现跨服务一致性、查询和运维策略
• 在同步（REST/gRPC）和异步（事件/消息传递）通信之间做出选择

使用方法

工作流

1. 映射限界上下文，以确定自然的服务边界
2. 定义聚合，在每个服务内确保数据一致性
3. 设计通信方式：查询和强一致性场景使用同步通信；解耦场景使用异步通信（领域事件）
4. 确保数据所有权：每个服务拥有自己的数据库；通过 API 或事件共享数据

1. 限界上下文到服务的映射

E-Commerce Domain:
├── Order Service        ← Order bounded context
│   ├── Order aggregate
│   └── OrderPlaced event
├── Inventory Service    ← Inventory bounded context
│   ├── Product aggregate
│   └── StockReserved event
├── Payment Service      ← Payment bounded context
│   ├── Payment aggregate
│   └── PaymentCompleted event
└── Notification Service ← Cross-cutting
    └── Subscribes to all domain events

2. 同步通信（Feign/gRPC）

@FeignClient(name = "inventory-service")
public interface InventoryClient {
    @GetMapping("/api/products/{id}/stock")
    StockInfo getStock(@PathVariable String id);
}

3. 异步通信（领域事件）

// Order Service publishes
@Transactional
public void placeOrder(PlaceOrderCommand cmd) {
    Order order = Order.create(cmd);
    orderRepository.save(order);
    eventPublisher.publish(new OrderPlacedEvent(order.getId(), order.getItems()));
}

// Inventory Service subscribes
@EventListener
public void onOrderPlaced(OrderPlacedEvent event) {
    inventoryService.reserveStock(event.getItems());
}

4. 每个服务使用独立数据库

Order Service      → order_db (PostgreSQL)
Inventory Service  → inventory_db (PostgreSQL)
Payment Service    → payment_db (PostgreSQL)

最佳实践

• 在拆分为服务之前，先清晰定义限界上下文；避免过早拆分
• 使用领域事件表达跨聚合和跨服务的事实；确保幂等性和顺序性
• 为每个服务定义明确的 SLA、数据所有权和故障边界
• 优先采用带补偿事务（Saga 模式）的最终一致性，而非分布式事务

资源

• Sam Newman 著《Building Microservices》
• Eric Evans 著《Domain-Driven Design》
• https://microservices.io/

关键词

DDD 微服务、限界上下文、聚合、领域事件、服务边界、Saga 模式、CQRS、每个服务独立数据库、最终一致性、API 网关