DDD の境界付きコンテキストを使用してサービス境界をどのように定義しますか?

Question

Accepted Answer

優れたサービス境界は**ビジネス機能**に従っており、技術層には従っていません。**ドメイン駆動設計 (DDD)** はこのための正確なツールを提供します：**境界付きコンテキスト** — ドメインモデルとその用語が一貫性を持つ境界です。

## 境界付きコンテキスト

「Customer」という言葉は、異なるコンテキストで異なる意味を持つことができます。各境界付きコンテキストは独自のモデルを所有し、マイクロサービスは通常 1 つのコンテキストにマップされます。

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

## 境界を見つける方法

- **ビジネス機能** (注文、請求、配送) に整合させます。名詞や DB テーブルではなく。
- 境界内で**高凝集性**、境界を越えて**疎結合**。
- **ユビキタス言語**が変わる場所を観察してください — それは通常、コンテキスト境界です。
- **コンテキストマップ**を使用して関係 (アップストリーム/ダウンストリーム) を文書化します。

## アンチパターン

```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
```

2 つのサービスが 1 つの操作を完了するために常に相互に呼び出す場合、その境界はおそらく間違っています。

## なぜ重要なのか

早い段階で決定された境界は、後で移動するのに非常にコストがかかります。なぜなら、それらは他のチームが依存する API とデータベースに硬化するからです。

DDD 境界付きコンテキストは、ビジネスに沿ってこれらの線を引くための原則的な方法を提供するため、サービスは凝集力を保ち、常に調整するのではなく独立して進化することができます。