データベース・パー・サービス原則とは何ですか？

Question

Accepted Answer

**データベース・パー・サービス**とは、各マイクロサービスが独自のプライベートデータベースを所有し、他のサービスがそれを直接読み書きできないことを意味します。他のサービスは、所有するサービスの API を通じてアクセスする必要があります。

## 動作方法

```text
┌──────────┐     ┌──────────┐     ┌──────────┐
│  Orders  │     │ Payments │     │  Users   │
│ service  │     │ service  │     │ service  │
└────┬─────┘     └────┬─────┘     └────┬─────┘
     ▼                ▼                ▼
  ordersDB        paymentsDB        usersDB   ← private, no cross-access
```

Orders が ユーザーデータが必要な場合、Users API を呼び出します — `usersDB` に直接クエリを実行しては**いけません**。

## 強制する理由

- **疎結合** — サービスはスキーマを自由に変更できます。
- **独立したデプロイ** — チーム間での共有スキーママイグレーションがありません。
- **技術選択** — あるサービスは Postgres を使用し、別のサービスは MongoDB を使用できます。

## コスト

```text
With no shared DB:
  ✗ no cross-service JOINs
  ✗ no single ACID transaction across services
  → need API composition, replication, or sagas instead
```

## 落とし穴

**共有データベース**は古典的なアンチパターンです — サービスを暗黙的に結合し、独立してデプロイできなくなります。

## なぜ重要なのか

プライベートデータベースはサービスを実際に独立させるもので、データベースを共有すればそれは分散モノリスになってしまいます。

その代価は、結合とトランザクションがサービス間に及ぶようになり、サgas やイベンチュアルコンシステンシーなどのパターンを強制されることです — これは自律性のための意図的なトレードオフです。