はじめに ─ DB の形は最後に決められるのか、それとも最初に決まるのか

こんな違和感を、設計のたびに感じていないか

新しいサービスを設計する場面。あなたの手元にはユースケースとドメインモデルがある。Aggregate を引き、Bounded Context を切り、Repository を定義する。

ここまで来て、ふと立ち止まる。

「で、永続化は何にする？」

DDD の本には書いてある ── “The Database is a Detail”（Robert Martin）、“the model is not the database”（Eric Evans）。永続化は最後に決められる詳細なのだ、と。

ところが現実はそう優しくない。Aggregate のサイズを決めようとした瞬間、トランザクション境界が DB の特性に依存することに気づく。UPDATE で 10 行を atomic に書きたい ── これが PostgreSQL なら自然、DynamoDB なら 25 件までの TransactWriteItems、複数リージョン跨ぎなら Spanner が要る。

つまり「永続化は詳細」と言いながら、詳細が設計を縛り返す。

逆のアプローチもある。AWS の Werner Vogels は “One size doesn’t fit all” と言い、DynamoDB の Rick Houlihan は “Start from access patterns” と言う。ワークロードを見て DB を決め、DB が schema を決め、schema が API を決める。ドメインは最後に滲み出てくる。

この二つの流派は、対立しているのか。それとも別レイヤーの話なのか。

このシリーズが目指すこと

本記事は「正規化」も「SQL アンチパターン」も扱わない。代わりに、DB を設計するときの “外さない軸” を、ドメイン駆動と特性駆動という二つの流派の対比を通して提示する。

具体的には：

• 第 1-3 章でドメイン駆動と特性駆動の地図を立てる
• 第 4-15 章で 6 つのワークロード（OLTP / OLAP / Cache / NoSQL / Stream / NewSQL）を、それぞれ「本質編」と「設計編」の 2 章で深掘りする
• 第 16 章で「ドメインから使われる側 = 共通基盤としての DB 設計」に踏み込む（Stripe の Idempotency、Multi-tenant 分離、Schema 進化）
• 第 17-18 章で Polyglot Persistence と、両派を行き来する設計判断のフレームを統合する
• 第 19 章で「外さない 9 つの軸」をチェックリストとして残す

対象読者

• Aggregate の設計はできるが、永続化選定で迷うエンジニア
• 共通基盤やプラットフォーム側の DB を設計する立場になり、ドメイン側との接続に違和感を持っている人
• 「DDIA は読んだが、自分の現場でどう使えばいいか分からない」人
• 複数の DB（RDB / NoSQL / Redis / NewSQL / Stream）を実務で触っているが、それらを統一した観点で見られていない人

「正規化とは何か」レベルから始める入門書ではない。

全 19 章の構成

章	テーマ
1	ドメインから入るか、特性から入るか ─ 二つの流派
2	ドメイン視点の地図 ─ Aggregate / Bounded Context / Repository
3	ワークロード視点の地図 ─ 6 軸でデータを見る
4	OLTP の本質 ─ MVCC・WAL・行指向
5	OLTP 設計の意思決定 ─ Aggregate 境界・Hot row・Index・進化
6	OLAP の本質 ─ 列指向・Bulk read という別世界
7	OLAP 設計の意思決定 ─ Sort key・Dimensional Modeling・MV
8	Cache の本質 ─ 揮発性・データ構造・Tier
9	Cache 設計の意思決定 ─ Cache-aside・TTL・Stampede・Key 設計
10	KV / Document NoSQL の本質 ─ Partition と Eventual Consistency
11	NoSQL 設計の意思決定 ─ アクセスパターン・Hot partition・GSI
12	Stream / Event Sourcing の本質 ─ append-only と時間
13	Stream 設計の意思決定 ─ イベント粒度・Partition・Schema 進化
14	Geo-distributed / NewSQL の本質 ─ TrueTime・Raft・地理分散
15	NewSQL 設計の意思決定 ─ Region 配置・Locality・Consistency level
16	ドメインから使われる側 ─ 共通基盤としての DB 設計
17	Polyglot Persistence ─ 複数 DB を持つときのドメイン側の構え
18	両派を行き来する ─ Aggregate と Partition Key、Repository の壁
19	外さない 9 つの軸 ─ ドメイン × 特性 × 共通基盤のチェックリスト

読み方の選択肢

19 章は長い。読了の目安は 通読で 3-4 時間。読み方は 3 通り想定している：

A. 通読（推奨）

第 1 章 から順に読む。各章末の「次章への問いかけ」が次章を引っ張る構造で、1 章で投げた “両派は対立するのか” の問いが、4-15 章の各ワークロードで具体に降ろされ、16 章で共通基盤という両派が衝突する場所を扱い、17-18 章で行き来する作法に統合され、19 章でチェックリストに収束する。伏線回収を楽しむなら通読を。

B. 関心領域だけ読む

• DDD と DB の関係に違和感がある人：第 1-2 章 → 第 18 章
• 共通基盤の設計に不慣れな人：第 16 章 を直接読む（前提となる用語が少ない）
• 特定ワークロードの設計が知りたい人：本質編 + 設計編を 2 章セットで（例：OLTP なら 第 4 章 + 第 5 章）

C. リファレンスとして使う

第 19 章「外さない 9 つの軸」 のチェックリストから、その軸の根拠章へジャンプする。設計レビュー時の道具として。

読み方

各章末に次章への問いかけを仕込んでいる。流し読みでも筋は追えるが、章末の問いを意識して読むと伏線の張り方が見える。各章は単独でも読めるが、シリーズ全体は “両派の橋を架ける” ために設計されている。

それでは始めよう。第 1 章 は「二つの流派」の地図から。