2026年のDDD論争総覧 ── Anemic・DCB・Vertical Slice・AI時代

本章の方針

2003年の青本刊行から20年以上が経った2026年、DDDは 過去最も揺さぶられている。「Kill Aggregate!」と集約の死を唱える提案、「レイヤリング不要」と語る Vertical Slice、「LLMがコードを書くならモデリング不要」という急進的な意見── これらの論争は無視できない。

本章では、2026年時点の主要な7つの論争を整理し、それぞれに対する本記事の立場 を明示する。読者はこの地図を使って、自分の立ち位置を決めてほしい。

---

論争1：Anemic Domain Model ── 20年続く答えの出ない議論

発端

2003年、Martin Fowler が記事 “AnemicDomainModel” で、「データだけのオブジェクトとロジック専用のサービスクラス」という設計を アンチパターン として批判した。彼はこれを「貧血症」と形容した。

批判者の主張

• Entity が単なるデータホルダなら、オブジェクト指向の利点が失われる
• 振る舞いとデータが離れると、カプセル化が崩れる
• 結果的に、Transaction Script と変わらない

支持者の主張（2026年時点で強まっている）

• 関数型プログラミング的な視点では、データと振る舞いの分離は自然（Scott Wlaschin が “Domain Modeling Made Functional” で体系化）
• TypeScript のような構造的型システムでは、データ構造 + 純粋関数 の組み合わせの方が扱いやすい
• ORMとの統合を考えると、Anemic な方がシンプル
• 「Rich Domain Model」の多くは実際には カプセル化の迷信 にすぎない

2026年の潮流

「Anemic 対 Rich」の二項対立自体が古い、という新しい立場が広がっている。代わりに以下のような言い方が増えた。

・状態と状態遷移ルールを持つ Entity → メソッドを持たせる（Rich）
・単なる読み取り用の投影やDTO → メソッドを持たせない（Anemic）
・用途によって使い分ける

本記事の立場

Rich Domain Model を原則としつつ、Query側（読み取り）は Anemic で良い。CQRSの採用が両者の折り合いを付ける鍵。全てを Rich にする必要も、全てを Anemic にする必要もない。

---

論争2：Kill Aggregate! ── DCB の登場

発端

2023年4月、Sara Pellegrini がブログ記事 “Kill Aggregate!” を公開。集約（Aggregate）を 死んだパターン と断じ、代わりに Dynamic Consistency Boundary（DCB） を提案した。

その後、Bastian Waidelich と Paul Grimshaw を加えた3名でDCBの仕様を策定。dcb.events をオープンプラットフォームとして公開し、DDD Europe などのカンファレンスで議論が広がった。

DCBの核心

集約：設計時に固定した静的な一貫性境界
DCB：実行時にイベントのタグの交わりとして動的に決まる一貫性境界

具体例：

• 「1講座に最大30名」と「1人に最大10講座」を 同時に保証 する場合、集約ではどちらか一方しか守れない
• DCBでは course_id=C1 と student_id=S1 のタグを持つイベントの交わりだけで一貫性を検証できる

批判者の主張

• Event Sourcing 前提で、既存システムには導入コスト高
• ツール・ライブラリの成熟度が低い（2026年時点でも）
• 「動的境界」の設計は、静的境界より難しい
• 実務で成功事例が少ない

支持者の主張

• 集約の限界（2つの軸にまたがるルール）に正面から答える唯一のアプローチ
• イベントソーシングとの相性が極めて良い
• Saga や補償トランザクションの複雑性を解消する

2026年の潮流

DCB は 一部の先進的チーム で実装が始まっている段階。Axon Framework、Event Store、独自実装など複数の実装が存在する。しかし、大規模エンタープライズでの採用事例はまだ限定的。

本記事の立場

・集約は依然として主要パターン。まず集約で設計を試みる
・集約で表現困難なルールがあり、かつ Event Sourcing を採用するなら DCB を検討
・Event Sourcing を採用しないなら、DCB の恩恵は限定的
・学習価値は高い（「集約とは何だったか」を問い直せる）

詳細は姉妹記事 DCB（Dynamic Consistency Boundary） に譲る。

---

論争3：Vertical Slice Architecture ── レイヤリングへの反逆

発端

Jimmy Bogard が2010年代後半に提唱した Vertical Slice Architecture。ここ数年で強い支持を集めている。

Vertical Slice の核心

従来のレイヤリング（水平分割）：
  Controller層 / Application層 / Domain層 / Infrastructure層
  → 1機能を追加するのに全層を変更する

Vertical Slice（垂直分割）：
  features/
    UpgradeSubscription/
      Command.ts
      Handler.ts
      Validator.ts
      Repository.ts
  → 1機能が1フォルダに閉じる。変更影響が限定的

1ユースケース = 1スライス で、スライス内は自由に設計する。共通処理の抽出は 痛みを感じてから 行う（“Don’t abstract until it hurts”）。

批判者の主張（伝統的DDD派）

• ドメインモデルが散らばる
• 重複コードが増える
• ユビキタス言語の維持が難しい
• 集約の境界が見えなくなる

支持者の主張

• 機能追加のスピードが速い
• 変更の影響範囲が1フォルダに閉じる
• 実際のソフトウェアの変更単位は「機能」であり、「層」ではない
• DDDのレイヤリングは過剰

2026年の潮流

Vertical Slice は 中小規模の新規プロジェクト で採用が拡大。大規模・長寿命なシステムでは依然DDDレイヤリングが主流。ハイブリッド的な実装──「境界コンテキスト内は Vertical Slice、共有ドメイン層は DDD」──も増えている。

本記事の立場

・「DDD か Vertical Slice か」の二者択一ではない
・スタートアップや新規機能の開発初期：Vertical Sliceが合理的
・モデルが成熟し、ドメインルールが複雑化したフェーズ：DDDへのリファクタ
・最初から全ての集約を設計する必要はない

---

論争4：Functional DDD ── Scott Wlaschin が切り開いた道

発端

Scott Wlaschin が2017年に “Domain Modeling Made Functional”（fsharpforfunandprofit.com でも展開）を出版。F#（関数型言語）でのDDD実践 を体系化し、代数的データ型と純粋関数によるドメインモデリングを提案した。

Functional DDD の核心

// 状態遷移を「型」で表現する
type UnpaidInvoice = ...
type PaidInvoice = ...
type PayInvoice = UnpaidInvoice -> Payment -> PaidInvoice
// 型の時点で「支払済みをさらに支払う」が不可能になる

TypeScript でも同じアプローチが可能だ。Discriminated Union を使って状態遷移を型で表現する。

type Subscription =
  | { status: 'trial'; customerId: CustomerId; trialEndsAt: Date }
  | { status: 'active'; customerId: CustomerId; currentPeriod: BillingPeriod }
  | { status: 'canceled'; customerId: CustomerId; canceledAt: Date }

// 型安全に状態遷移を書ける
function activate(sub: Extract<Subscription, { status: 'trial' }>): Extract<Subscription, { status: 'active' }> {
  return { status: 'active', customerId: sub.customerId, currentPeriod: ... }
}
// trial 以外を渡すとコンパイルエラー

2026年の潮流

関数型DDDは TypeScript / Elixir / Scala / Rust のコミュニティで強い支持を得ている。「OOP的 DDD」と「関数型 DDD」は互換ではなく、別のスタイル として両立する段階に入った。

本記事の立場

・関数型DDDは TypeScript の Discriminated Union と極めて相性が良い
・「状態遷移ルールを型で表現する」アプローチは全てのプロジェクトで有効
・OOP的DDDにこだわる必要はない。両者のいいとこ取りで良い

---

論争5：AI時代、ユビキタス言語は必要か

発端

2024〜2025年にかけて、LLM（GitHub Copilot、Claude、Cursor、Windsurf）のコード生成精度が劇的に向上。2026年現在、新規コードの相当割合がAI生成となっている。この文脈で「DDDは必要か」論争が起きている。

「不要になる」派の主張

• LLMはコードベース全体を理解できる。「層をまたぐ変更」のコストが下がった
• リファクタがほぼ無料になったため、「最初から綺麗な設計」の価値が低下
• 複雑なパターンを人間が理解する必要がなくなる
• Vertical Slice のような「1機能1フォルダ」のほうが LLM にとって扱いやすい

「より重要になる」派の主張

• LLM は「コードは書ける」が「ビジネスルールを理解していない」
• ユビキタス言語が揃ったコードは、LLMの生成精度を大幅に向上させる
• 型で表現されたドメインモデルは LLMにとっての仕様書 として機能する
• 境界づけられたコンテキストは LLM の コンテキスト窓の自然な境界 として機能する

2026年の潮流

「LLM × DDD」の研究が急速に進む。特に ユビキタス言語のメタデータ化（OpenAPI の Glossary 拡張、GraphQL の Description 強化など）が議論されている。

本記事の立場

・AI時代こそユビキタス言語の価値が高まる
・型で表現されたドメイン（Value Object、Discriminated Union）が LLM の理解を助ける
・ただし「レイヤリング」のような人間向けの抽象はAI時代には冗長になる可能性
・「人間が読むためのDDD」から「人間とAIが共有するためのDDD」へ

---

論争6：Modular Monolith 復権 ── マイクロサービス疲れの終着点

発端

2010年代のマイクロサービスブームが一段落し、2023〜2025年にかけて Modular Monolith への回帰が顕著になった。著名な事例としては、Shopify や GitHub の社内アーキテクチャ、Basecamp の “Majestic Monolith” 哲学など。

Modular Monolith の核心

・単一のデプロイユニット（モノリス）
・内部は境界づけられたコンテキストで分割
・コンテキスト間は明示的なインターフェースで通信（関数呼び出しだが疎結合）
・必要になったら、モジュール単位で独立サービスに切り出す

DDD との関係

Modular Monolith は 戦略的DDDをモノリス内で実現する アプローチだ。戦術的DDDもモジュール内で使える。マイクロサービスより 分散システムの複雑性が無い 分、DDDの恩恵を受けやすい。

2026年の潮流

新規プロジェクトの 第一選択肢として Modular Monolith が推奨される 傾向が強い。「マイクロサービスから始めるのは早すぎる最適化」という認識が定着した。

本記事の立場

・Modular Monolith は2026年における新規プロジェクトの第一選択肢
・戦術的DDDは、Modular Monolith の各モジュール内で最大の価値を発揮する
・マイクロサービスに分解するのは、ビジネス要件で必要になってから
・早すぎるマイクロサービス化は、DDDとも相性が悪い

---

論争7：「DDDやりすぎ」批判 ── DHH系の実用主義

発端

David Heinemeier Hansson（DHH、Ruby on Rails 作者） らを中心とする実用主義派は、長年DDDに批判的だ。2020年代に再燃した議論として、“Programming Should Be Simple” 的な主張がある。

批判者の主張

• 多くのプロジェクトに戦術的DDDは過剰
• Rails の ActiveRecord + Fat Model で十分
• 抽象化コストが、得られる価値に見合わない
• 「Entity・Value Object・Service」という用語法自体が Java 文化圏のもの

支持者の主張（DDD側の反論）

• 複雑なドメインではActiveRecordは破綻する
• DHHの「シンプルさ」は小規模アプリに特化している
• 戦略的DDDは組織設計の問題であり、実装スタイルとは独立

2026年の潮流

「プロジェクトの規模・ドメインの複雑さに応じてDDDの深度を調整する」 という折衷案が主流化。「DDD原理主義」は終わり、「pragmatic DDD」が標準になった。

本記事の立場

・単純な CRUD アプリには DDD は不要
・Rails/Django/Laravel などの「フレームワーク＋ActiveRecord」で十分なケースは多い
・DDDは「ドメインの複雑さが実際に痛みを生んでいる」ことが前提
・「DDDを採用しない判断」も DDD の知識を持っていてこそ下せる

---

論争マップ：全体像

mindmap
  root((2026年のDDD論争))
    Anemic vs Rich
      Martin Fowler 2003
      関数型の台頭で再燃
      2026の折衷：CQRSで両立
    Kill Aggregate
      Sara Pellegrini 2023
      DCB提案
      Event Sourcing前提
    Vertical Slice
      Jimmy Bogard
      レイヤリングへの反逆
      中小規模で優勢
    Functional DDD
      Scott Wlaschin
      F#/TS/Rust/Elixir
      型で状態遷移を表現
    AI時代
      LLMのコード生成
      ユビキタス言語の再評価
      型=LLMの仕様書
    Modular Monolith
      マイクロサービス疲れ
      新規はまずモノリス
      戦術的DDDの恩恵大
    DDDやりすぎ批判
      DHH系実用主義
      ActiveRecord再評価
      pragmatic DDDへ収束

---

本章のまとめ：7つの論争に対する筆者の総論

・DDDは死んでいない。むしろ「pragmatic DDD」として成熟している
・「全てのDDDパターンを使う」時代は終わった
・プロジェクトの性質に応じてパターンを選ぶ時代になった
・Anemic vs Rich は CQRS で両立する
・集約は依然として主要パターン。DCBは集約を超える選択肢として並列
・Vertical Slice と DDDレイヤリングは用途が違う
・Functional DDD は OOP-DDD の補完
・AI時代は DDD の価値を再定義する（型＝LLMの仕様書）
・Modular Monolith は DDD の恩恵を最大化する
・DDDやりすぎ批判は正当。適用判断が重要

次章（最終章）では、これらの論争を踏まえた上で、自分のプロジェクトにDDDをどう適用するか の判断軸と段階的導入戦略をまとめる。

＋ － ⟳ ✕