你如何使用DDD bounded contexts来定义服务边界？

Question

Accepted Answer

良好的服务边界应遵循**业务能力**，而不是技术层。**领域驱动设计（DDD）**为此提供了一个精确的工具：**bounded context**——一个边界，在这个边界内域模型及其术语保持一致。

## Bounded context

"Customer"这个词在不同的上下文中可能有不同的含义。每个bounded context拥有自己的模型，一个微服务通常映射到一个context。

```text
┌───────────────────┐   ┌────────────────────┐
│  Sales context    │   │  Support context   │
│  Customer =       │   │  Customer =        │
│   leads, orders   │   │   tickets, SLAs    │
└───────────────────┘   └────────────────────┘
   one service             another service
```

## 如何找到边界

- **与业务能力对齐**（订单、计费、配送），而不是名词或数据库表。
- **内部高内聚，跨边界松耦合**。
- 观察**通用语言**在哪里发生变化——那通常就是context的边界。
- 使用**context map**来记录关系（上游/下游）。

## 反模式

```text
✗ Entity services ("User service", "Product service") — too fine, chatty
✗ Splitting by technical layer (a "database service")
✗ Boundaries that force a distributed transaction for every operation
```

如果两个服务需要不断地相互调用才能完成一个操作，那么边界可能就是错误的。

## 为什么这很重要

早期决定的边界后来移动成本非常高，因为它们会硬化为其他团队依赖的API和数据库。

DDD bounded context为你提供了一种原则性的方式来沿着业务划分这些边界，使得服务保持内聚，可以独立演进，而不是不断地相互协调。