データモデル設計ガイド
どちらを選ぶか — DDD / 非 DDD の判断軸
業務複雑度・チーム規模・読み書き比率・マイクロサービス化の有無から、DDD / 非 DDD / 折衷の選択を整理する。
結論の先出し — 二者択一ではない
ここまで見てきた通り、DDD と非 DDD は「どちらが正しいか」ではなく「どの部分にどの設計を当てるか」の問題です。現実のプロジェクトでは、次のような折衷が最も頻繁に現れます。
- コア業務領域（注文・在庫・会計）は DDD 的に集約を切る — 不変条件が強く、将来の分割可能性も高い
- 周辺領域（マスタ管理、管理画面、レポート）は非 DDD の素直な正規化 — 読み取り中心で業務ルールが薄く、JOIN で一覧化できた方が楽
- 読み取り側は JOIN を許可 — 集約境界は主に書き込み側の概念として運用
- 物理 FK は多くのケースで張る — 運用とクレンジングのため。集約境界はアプリ側の規律で守る
つまり「集約境界で書き込み整合性を守り、読み取りは自由に JOIN する」くらいの使い方が、多くの業務システムでバランスが取れます。
判断軸 — 4 つの観点
DDD 寄りに倒すほど得になるか、非 DDD 寄りに倒すほど得になるかは、次の 4 軸で大きく決まります。
| 軸 | DDD が適する | 非 DDD が適する |
|---|---|---|
| 業務複雑度 | 業務不変条件が多く、業務ロジックが DB の外に多い（金融・会計・医療・EC の注文周りなど） | CRUD 中心で業務ルールが薄い（マスタ管理、情報系アプリ、社内ツール） |
| 読み書き比率 | 書き込みの整合性が強く問われる（金額・在庫・権限） | 読み取りが圧倒的で、画面一覧が複雑（分析・レポート） |
| チーム規模 | 複数チームが同じ DB を触る（境界がないと互いに踏む） | 小規模チーム 1 つで全部見る（境界を守るコストが相対的に重い） |
| サービス分割 | 近い将来にドメイン単位で分割予定 | 当面モノリス継続、分割の動機がない |
4 軸すべてで左列に寄るならフル DDD、すべてで右列に寄るならフル非 DDD、ほとんどのプロジェクトは混在します。だからこそ「全部 DDD」「全部非 DDD」で統一しようとすると歪みが出ます。
DDD 側のコスト — 言語化しておく
DDD 側のコストは次のとおりで、これを許容できるかは現実的な判断ポイントです。
- 設計の初期コスト — 集約境界を決める議論がプロジェクト序盤で必要。ドメイン知識がチームに薄いと、境界を切り直すコストが高い
- 読み取りクエリの複雑化 — 集約を跨ぐ一覧・集計は素直に書きづらく、CQRS やビュー整備が必要になることがある
- スナップショットによるデータ重複 — 商品名や価格のコピーが集約内に残り、ストレージ・更新ルール・分析クエリの前提が複雑になる
- 結果整合性の運用負荷 — 集約間が非同期になる場合、失敗時のリカバリ・補償トランザクションの設計が別途必要
- 学習コスト — チーム全員が集約の規律を守れないと、中途半端な DDD が一番事故を生む
非 DDD 側のコスト — 言語化しておく
一方で非 DDD（素直な正規化中心）にも次のようなコストがあります。
- 業務ルールが DB の外側に散る — 「注文確定時にやること」がサービス層・バッチ・トリガーに散らばり、一貫した業務不変条件の把握が難しくなる
- トランザクション肥大化 — 業務処理が FK 網を辿るため、1 回の処理で触るテーブルが増え、ロック競合やデッドロックが増える
- スキーマ変更の波及 — テーブル間が広く FK でつながるため、列の追加・型の変更が複数サービス・複数画面に同時に影響する
- サービス分割の困難 — 後からマイクロサービスに分割したいとき、FK を 1 本ずつ剥がす作業になる
- 長期的な劣化 — 「ポリモーフィック関連」「過剰な NULL 列」など、正規化から外れるアンチパターンをチームが気づかず採用しやすい
実務的な進め方
新規プロジェクトでも既存プロジェクトでも、次の順序が最も事故が少ないです。
- まず 3NF まで正規化する（正規化とは）
- 業務不変条件を列挙する — 「明細合計 = 注文合計」「在庫 ≥ 0」「キャプチャ済み合計 ≤ 注文合計」など
- 不変条件ごとに整合性単位を決める — 1 トランザクションで守るべき範囲 = 集約境界
- 集約をまたぐ部分は ID 参照で書く（物理 FK は原則張って、アプリ側で境界を越えた書き込みをしない規律を持つ）
- 読み取りは素直に JOIN で書く。一覧画面のパフォーマンス問題が出てきたら、その時点でビュー or CQRS を検討する
- DDD 的な集約設計を入れるのはコア業務領域だけ。マスタ管理・設定画面・社内ツールは非 DDD のままで十分
「いきなり全部 DDD にする」「いきなり全部非 DDD に戻す」のどちらも、後からの修正コストが高く、折衷的に育てるのが現実的です。
チェックリスト — どちらに倒すか迷ったら
このサブドメインを DDD 寄りにすべきかどうか、次の質問で確認できます。YES が多いほど DDD 寄り、NO が多いほど非 DDD 寄りで問題ないサインです。
- 書き込み時に複数テーブルにまたがる不変条件が 2 つ以上ある？
- 業務ルールが「DB で FK と CHECK を書けば終わる」レベルを超えている？
- 外部システムとの非同期な連携が業務フローに含まれる？
- 複数チームが同時にこの領域を触る予定？
- 近い将来（2〜3 年以内）にサービス分割の可能性がある？
- 「ここだけは壊れたら致命的」という整合性の重さがある（会計・在庫・権限など）？
逆に、次の質問で YES が多いなら、非 DDD の正規化中心で十分です。
- 画面のほとんどが単純な CRUD？
- 業務ルールはほぼ画面側のバリデーションだけ？
- チームが少人数・1 チームで回している？
- 読み取りが圧倒的に多く、書き込みは単純 INSERT / UPDATE？
- サービス分割の話題は当面出てこない？