外さない 9 つの軸 ─ ドメイン × 特性 × 共通基盤のチェックリスト

シリーズの結びとして、ここまで散りばめた論点を 9 つの軸 に集約する。新規 DB 設計に取りかかるとき、または既存 DB を見直すとき、この 9 軸を順に点検すれば致命的な外しは避けられる、という実用チェックリスト。

軸 1：Bounded Context を引いたか

□ システムの Bounded Context は明確か？
□ 各 Context のドメインモデルは独立しているか？
□ 共通基盤を別 Context として扱っているか？

外す典型：「全部 1 つの DB にひとまとめ」「ドメインの境界が曖昧で、DB schema が肥大」

思い出すべき章：第 2 章（ドメイン視点の地図）、第 17 章（Polyglot Persistence）

軸 2：ワークロードを 6 軸で測ったか

□ read/write 比率は把握しているか？
□ レイテンシバジェットを 1 桁単位で決めたか？
□ 整合性モデル（Strong / Snapshot / Causal / Eventual）を選択したか？
□ データ形状（行 / 列 / KV / Document / Stream / Graph）を意識したか？
□ データ寿命（Hot / Warm / Cold / Forever）を見積もったか？
□ スケール軸（Vertical / Sharding / Geo-distributed）を決めたか？

外す典型：「とりあえず PostgreSQL」「流行ってるから NoSQL」── 6 軸を見ずに選んでいる

思い出すべき章：第 3 章（ワークロード視点の地図）

軸 3：Aggregate と Partition を整合させたか

□ Aggregate の境界を引いたか？（Vernon: 小さく保て）
□ 1 Trans = 1 Aggregate になっているか？
□ Aggregate ≒ Partition Key の対応関係が成立するか？
□ DB の Trans 制約（DynamoDB の 25 件等）に当たらないか？

外す典型：Aggregate を巨大にしてロック競合を起こす / 複数 Aggregate にまたがる Trans を多発させる

思い出すべき章：第 5 章（OLTP 設計）、第 11 章（NoSQL 設計）、第 18 章（両派の行き来）

軸 4：Source of Truth を 1 つに決めたか

□ Source of Truth はどの DB か？
□ それ以外は「派生（projection）」として扱っているか？
□ projection は Source から再生可能か？
□ 「複数の DB が両方とも正」という設計になっていないか？

外す典型：Postgres と Kafka の両方を “正” として扱い、不整合が発生する

思い出すべき章：第 12 章（Stream 本質）、第 17 章（Polyglot）

軸 5：DB 間の同期を Outbox / CDC で行うか

□ Dual Write を避けているか？
□ 複数 DB の atomic な更新は Outbox Pattern で実装しているか？
□ または CDC（Debezium 等）を使っているか？
□ Schema 進化に Avro / Protobuf + Registry を使っているか？

外す典型：「Postgres 更新 → Kafka publish」を直列に並べて、片方が失敗すると整合性が崩れる

思い出すべき章：第 13 章（Stream 設計）、第 17 章（Polyglot）

軸 6：Hot Partition / Hot Row を避けたか

□ Partition Key / 主キーの分散性を確認したか？
□ シーケンシャル ID（BIGSERIAL）が hot row を生んでいないか？
□ UUIDv7 / ULID 等の時系列＋分散 ID を検討したか？
□ Counter は sharding しているか、Stream に逃しているか？
□ Tenant 単位の Bulkhead はあるか？

外す典型：1 行の counter に書き込みが殺到、auto increment ID で last page contention

思い出すべき章：第 5 章（OLTP 設計）、第 11 章（NoSQL 設計）、第 15 章（NewSQL 設計）、第 16 章（共通基盤）

軸 7：Schema の進化戦略があるか

□ Schema 変更は段階的に行えるか？（追加 → 並走 → 移行 → 削除）
□ Avro / Protobuf の互換性ルールを守っているか？
□ API は version 化されているか？（path / header / 日付）
□ Online schema change が必要な操作は識別できているか？
□ 大量データの ALTER は分割して実行する仕組みがあるか？

外す典型：1 回のリリースで ALTER TABLE を強行 → 運用停止

思い出すべき章：第 5 章（OLTP 設計）、第 13 章（Stream 設計）、第 16 章（共通基盤）

軸 8：共通基盤の作法を持っているか

□ Idempotency キーで再試行を吸収しているか？
□ Multi-tenant の分離戦略を選択したか？
□ Hot tenant 対策（Token bucket / Bulkhead / Quota）はあるか？
□ Append-only audit log で変更履歴を残しているか？
□ Repository が DAO に堕ちる宿命を受け入れているか？

外す典型：共通基盤に DDD の Repository パターンを無理に適用、API の retry が二重請求を生む

思い出すべき章：第 16 章（共通基盤としての DB 設計）

軸 9：Polyglot を必要十分に保ったか

□ いきなり Polyglot にしていないか？
□ 単一 DB で足りる場面で複数 DB に分けていないか？
□ Bounded Context が分かれてから Polyglot に進んでいるか？
□ 各 DB の運用負担（バックアップ / 監視 / SRE）が見合っているか？

外す典型：「分析だから ClickHouse」を気軽に追加、運用が人的に破綻

思い出すべき章：第 17 章（Polyglot Persistence）、第 18 章（両派の行き来）

9 軸の関係

graph TB
  subgraph "ドメイン視点（軸 1, 3）"
    A1[Bounded Context]
    A3[Aggregate ↔ Partition]
  end

  subgraph "特性視点（軸 2, 6, 7）"
    A2[6 軸ワークロード測定]
    A6[Hot 回避]
    A7[Schema 進化]
  end

  subgraph "Polyglot 視点（軸 4, 5, 9）"
    A4[Source of Truth]
    A5[Outbox / CDC]
    A9[Polyglot 採否]
  end

  subgraph "共通基盤視点（軸 8）"
    A8[Idempotency / Multi-tenant / Audit]
  end

  A1 --> A3
  A2 --> A3
  A3 --> A4
  A4 --> A5
  A5 --> A9
  A8 -.横断.-> A1
  A8 -.横断.-> A4

  style A1 fill:#e1f5ff
  style A3 fill:#e1f5ff
  style A2 fill:#fff4e1
  style A6 fill:#fff4e1
  style A7 fill:#fff4e1
  style A4 fill:#ffe1e1
  style A5 fill:#ffe1e1
  style A9 fill:#ffe1e1
  style A8 fill:#e1ffe1

ドメイン視点（軸 1, 3）から始めて、特性視点（軸 2, 6, 7）と合流し、Polyglot 視点（軸 4, 5, 9）で複数 DB を扱い、共通基盤視点（軸 8）が横断的に関わる ── これが両派を行き来する設計の地図。

このシリーズが伝えたかったこと

第 1 章で投げた問い：「ドメイン駆動と特性駆動は対立しているのか、別レイヤーの話なのか」。

19 章を通って答えはこうだ：両者は別レイヤーの話だが、設計の現場では交わる。

• ドメイン側は「何を表現するか」を決める
• 特性側は「どう実装するか」を決める
• 両者は共通基盤という現実の場所で衝突し、合流する

あなたが今後 DB 設計に向き合うとき、覚えておきたい 5 つの原則：

1. ドメインから入っていい。Aggregate を引け
2. ただし永続化が “詳細” だと油断するな。Aggregate のサイズが DB の特性に縛られる
3. ワークロードを 6 軸で測れ。それなしに DB を選んではならない
4. 共通基盤に立つときは、Repository が DAO に堕ちることを受け入れろ
5. Polyglot は必要になってから。シンプルから始めろ

これらの原則は、上で挙げた 9 軸チェックリストの実行可能な要約だ。設計の起点で 5 原則、点検で 9 軸。これが「外さない軸」の運用形態になる。

参考文献・情報源

古典・基本書

• Eric Evans『Domain-Driven Design』
• Vaughn Vernon『実践ドメイン駆動設計』
• Vladimir Khononov『Learning Domain-Driven Design』
• Robert C. Martin『Clean Architecture』（特に Chapter 30: The Database is a Detail）
• Martin Kleppmann『Designing Data-Intensive Applications』(dataintensive.net)
• Sam Newman『Building Microservices』（2nd Edition）
• Adam Bellemare『Building Event-Driven Microservices』
• Pramod Sadalage & Martin Fowler『NoSQL Distilled』

Pat Helland 論文・記事

• Data on the Outside vs. Data on the Inside (CIDR 2005)
• Immutability Changes Everything (CIDR 2015)
• Mind Your State for Your State of Mind (QCon SF 2019)

Martin Fowler bliki

• Polyglot Persistence
• Bounded Context

Stream / Kafka

• Martin Kleppmann “Turning the database inside-out”
• Confluent: Turning the database inside-out with Apache Samza

NoSQL / DynamoDB

• Rick Houlihan: Single Table Design (re:Invent 2020)
• Rick Houlihan の 2024 年ツイート（STD deprecated）
• Alex DeBrie: The What, Why, and When of Single-Table Design

共通基盤・Idempotency

• Stripe Engineering: Designing robust APIs with idempotency
• Brandur: Implementing Stripe-like Idempotency Keys in Postgres

NewSQL / Geo-distributed

• Spanner: TrueTime and external consistency (Google Cloud Docs)
• CockroachDB design.md
• CockroachLabs: Living without atomic clocks

OLAP / 分析

• Altinity: ClickHouse Pick Keys
• yuzutas0（風音屋）: 30 分でわかるディメンショナルモデリング
• yuzutas0 訳『アジャイルデータモデリング』（講談社サイエンティフィク）
• yuzutas0 共著『実践的データ基盤への処方箋』（技術評論社）

Cache / Redis

• Redis 公式 GitHub
• antirez (Salvatore Sanfilippo) の関連記事

Werner Vogels / AWS

• Werner Vogels: A Decade of Dynamo (Dynamo Paper 振り返り)
• AWS: Purpose-built databases overview

共通基盤・分散システムの古典

• Adrian Cockcroft（Netflix）の各種講演
• Brandur: API Versioning at Stripe（補足）

---

ここまで読んでくれた読者のあなたへ。DB 設計に正解はない。だが「外さないための軸」はある。それを 9 つに整理したのがこのチェックリスト。

次にあなたが新規 DB を設計するとき、この 9 軸を点検してから始めてほしい。それがこのシリーズのゴールだった。

＋ － ⟳ ✕