领域驱动设计与架构设计原则指导下的服务边界划分
每个服务应该只负责一个明确的业务功能,避免功能混杂。这是服务拆分的最基本原则。
// ✅ 好的拆分 - 职责清晰
├── UserService # 用户管理:注册、登录、信息维护
├── OrderService # 订单管理:创建、查询、取消订单
├── ProductService # 商品管理:商品信息、分类、库存
├── PaymentService # 支付管理:支付处理、退款、对账
└── NotificationService # 通知服务:短信、邮件、推送
// ❌ 不好的拆分 - 职责混杂
├── BusinessService # 包含用户、订单、商品所有逻辑
├── CommonService # 各种不相关的通用功能
└── UtilityService # 工具类混杂,边界不清
服务内部功能应该紧密相关(高内聚),而服务之间应该尽量减少依赖(低耦合)。
按照业务领域自然边界划分服务,避免跨领域的服务设计。
// 电商系统业务边界划分示例
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 用户域 │ │ 商品域 │ │ 交易域 │
│ - 用户管理 │ │ - 商品管理 │ │ - 订单管理 │
│ - 认证授权 │ │ - 库存管理 │ │ - 购物车 │
│ - 会员体系 │ │ - 分类管理 │ │ - 支付处理 │
└─────────────────┘ └─────────────────┘ └─────────────────┘
// 避免跨领域服务
❌ OrderUserService # 跨越订单和用户领域
❌ ProductPaymentService # 跨越商品和支付领域
┌─────────────────────────────────────────────────────────┐
│ 电商领域 (E-commerce Domain) │
├─────────────────┬─────────────────┬─────────────────────┤
│ 用户子域 │ 商品子域 │ 交易子域 │
│ (User Subdomain)│(Product Subdomain)│(Transaction Subdomain)│
│ │ │ │
│ ┌─────────────┐ │ ┌─────────────┐ │ ┌─────────────────┐ │
│ │用户限界上下文│ │ │商品限界上下文│ │ │ 订单限界上下文 │ │
│ │ - 用户聚合 │ │ │ - 商品聚合 │ │ │ - 订单聚合 │ │
│ │ - 认证聚合 │ │ │ - 分类聚合 │ │ │ - 购物车聚合 │ │
│ └─────────────┘ │ └─────────────┘ │ └─────────────────┘ │
│ │ │ │
│ ┌─────────────┐ │ ┌─────────────┐ │ ┌─────────────────┐ │
│ │认证限界上下文│ │ │搜索限界上下文│ │ │ 支付限界上下文 │ │
│ │ - 权限聚合 │ │ │ - 索引聚合 │ │ │ - 支付聚合 │ │
│ │ - 会话聚合 │ │ │ - 推荐聚合 │ │ │ - 退款聚合 │ │
│ └─────────────┘ │ └─────────────┘ │ └─────────────────┘ │
└─────────────────┴─────────────────┴─────────────────────┘
不同限界上下文之间的协作模式决定了服务间的通信方式。
// 1. 合作伙伴关系 (Partnership)
// 两个上下文紧密合作,共同演进
用户上下文 ←→ 认证上下文
// 2. 共享内核 (Shared Kernel)
// 共享部分模型,需要同步变更
商品上下文 ←→ 搜索上下文 (共享商品模型)
// 3. 客户方-供应方 (Customer-Supplier)
// 明确的上下游关系
订单上下文 → 支付上下文 (订单调用支付)
// 4. 遵奉者 (Conformist)
// 下游上下文遵从上游上下文的模型
物流上下文 ← 订单上下文 (物流遵从订单模型)
// 5. 防腐层 (Anticorruption Layer)
// 隔离外部系统的影响
支付上下文 ←─[防腐层]─→ 第三方支付系统
根据组织的业务功能模块来划分服务边界。
// 社交平台业务能力拆分
├── 用户服务 (User Service)
│ ├── 用户注册、登录、资料管理
│ ├── 关注关系、好友管理
│ └── 隐私设置、账户安全
│
├── 内容服务 (Content Service)
│ ├── 内容发布、编辑、删除
│ ├── 内容审核、分类
│ └── 内容推荐、热门算法
│
├── 互动服务 (Interaction Service)
│ ├── 点赞、评论、分享
│ ├── 收藏、转发、举报
│ └── 互动统计、排行榜
│
├── 消息服务 (Message Service)
│ ├── 私信、群聊
│ ├── 系统通知、推送
│ └── 消息队列、实时通信
│
└── 推荐服务 (Recommendation Service)
├── 用户画像、兴趣建模
├── 内容相似度计算
└── 个性化推荐算法
每个服务管理自己的数据库,实现数据自治。
// 数据边界划分示例
用户服务数据库:
├── users表 (用户基本信息)
├── user_profiles表 (用户资料)
├── user_relationships表 (用户关系)
└── user_security表 (安全信息)
商品服务数据库:
├── products表 (商品信息)
├── categories表 (商品分类)
├── inventory表 (库存信息)
└── product_reviews表 (商品评价)
订单服务数据库:
├── orders表 (订单主信息)
├── order_items表 (订单项)
├── shopping_carts表 (购物车)
└── order_logs表 (订单日志)
康威定律:系统架构反映组织沟通结构。
// 原单体应用 - 订单创建逻辑
@Service
public class OrderService {
@Autowired
private UserRepository userRepository;
@Autowired
private ProductRepository productRepository;
@Autowired
private InventoryRepository inventoryRepository;
@Autowired
private PaymentService paymentService;
public Order createOrder(OrderCreateRequest request) {
// 1. 验证用户 (用户领域逻辑)
User user = userRepository.findById(request.getUserId());
if (user == null || !user.isActive()) {
throw new UserNotFoundException();
}
// 2. 检查商品和库存 (商品领域逻辑)
Product product = productRepository.findById(request.getProductId());
if (product == null || !product.isAvailable()) {
throw new ProductNotFoundException();
}
Inventory inventory = inventoryRepository.findByProductId(request.getProductId());
if (inventory.getStock() < request.getQuantity()) {
throw new InsufficientStockException();
}
// 3. 扣减库存 (商品领域逻辑)
inventory.setStock(inventory.getStock() - request.getQuantity());
inventoryRepository.save(inventory);
// 4. 创建订单 (订单领域逻辑)
Order order = new Order();
order.setUserId(request.getUserId());
order.setProductId(request.getProductId());
order.setQuantity(request.getQuantity());
order.setTotalAmount(product.getPrice() * request.getQuantity());
order.setStatus(OrderStatus.CREATED);
Order savedOrder = orderRepository.save(order);
// 5. 调用支付 (支付领域逻辑)
PaymentResult paymentResult = paymentService.processPayment(
savedOrder.getId(), savedOrder.getTotalAmount());
// 6. 更新订单状态
savedOrder.setStatus(OrderStatus.PAID);
orderRepository.save(savedOrder);
return savedOrder;
}
}
// 拆分后的微服务架构
// 1. 订单服务 (Order Service)
@Service
public class OrderService {
@Autowired
private UserServiceClient userService;
@Autowired
private ProductServiceClient productService;
@Autowired
private PaymentServiceClient paymentService;
@Autowired
private EventPublisher eventPublisher;
@Transactional
public Order createOrder(OrderCreateRequest request) {
// 1. 验证用户 (调用用户服务)
UserDTO user = userService.getUser(request.getUserId());
if (user == null || !user.isActive()) {
throw new UserNotFoundException();
}
// 2. 验证商品和库存 (调用商品服务)
ProductAvailabilityDTO availability =
productService.checkAvailability(request.getProductId(), request.getQuantity());
if (!availability.isAvailable()) {
throw new ProductNotAvailableException(availability.getReason());
}
// 3. 创建订单 (订单领域核心逻辑)
Order order = Order.create(request, user, availability);
Order savedOrder = orderRepository.save(order);
// 4. 发布订单创建事件
eventPublisher.publish(new OrderCreatedEvent(savedOrder));
return savedOrder;
}
}
// 2. 商品服务 (Product Service) - 处理库存扣减
@Service
public class ProductService {
@EventListener
public void handleOrderCreated(OrderCreatedEvent event) {
// 异步处理库存扣减
inventoryService.deductStock(
event.getProductId(),
event.getQuantity()
);
}
}
// 3. 支付服务 (Payment Service) - 处理支付
@Service
public class PaymentService {
@EventListener
public void handleOrderCreated(OrderCreatedEvent event) {
// 异步处理支付
paymentProcessor.processPayment(event.getOrderId(), event.getAmount());
}
}