ドメインロジック ― Transaction Script vs DDD ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「アプリケーションアーキテクチャ」カテゴリ第2弾として、ドメインロジックについて解説する記事です。

ドメインロジックは「業務固有のルール・判断・計算」を担う層で、ここの設計品質がアプリの長期競争力を決めます。本記事では Transaction Script vs Domain Model（DDD）の2大スタイル、DDD戦術/戦略パターン、貧血ドメインモデルというアンチパターン、AI時代における「業務概念を型に昇格させる」価値まで解説します。

本記事のテーマについてさらに詳しく知りたい方は『ソフトウェアアーキテクチャの基礎』も参考にしてみてください。

そもそもドメインロジックとは何か

ドメインロジックとは、ざっくり言えば「そのアプリ固有の業務ルール・判断・計算をコードで表現したもの」です。

税理士の仕事を想像してください。帳簿のフォーマット（UI）や金庫（DB）は汎用品で誰でも買えますが、「この経費は控除対象か」「消費税率は8%か10%か」を判断する専門知識は税理士固有のものです。ソフトウェアも同じで、画面表示やDB保存は汎用的な仕組みで済みますが、「割引は5000円以上で10%」「退会後30日で匿名化」といった業務ルールはそのアプリだけのものです。この層をどう設計するかがアプリの長期的な品質を決めます。

なぜドメインロジックの設計が重要なのか

もしドメインロジックの設計を曖昧にしたらどうなるか。業務ルールがUIやDBに漏れていると、同じルールが複数箇所に散らばり、変更時に片方だけ直して矛盾が生まれる、という事故がよく起きます。ここが混沌としていると、業務変更のたびにコードが歪んでいきます。

アプリの価値はドメインロジックに宿ります。UI層（画面表示・入力検証）やインフラ層（DB・外部API）は汎用的ですが、ドメイン層だけはそのアプリ固有の競争力です。

3大スタイル

Martin Fowler が整理したドメインロジックの表現方式は、大きく3つに分類できます。プロジェクトの複雑さとチームの成熟度によって、どれを採用するかが変わります。

このうちTable Moduleはあまり使われず、実務では「Transaction Script vs Domain Model」の選択になることがほとんどです。

Transaction Script

Transaction Script は、リクエストごとに処理を手続き型で書いていくスタイルです。MVCフレームワークの Service 層によく見られる形で、最もシンプルで書き始めが速いのが特徴です。

function registerOrder(req) {
  const user = getUser(req.userId)
  if (!user.isActive) throw new Error()
  const stock = getStock(req.productId)
  if (stock < 1) throw new Error()
  const price = calcPrice(...)
  saveOrder(...)
  sendMail(...)
}

CRUD中心のシンプルな業務なら、Transaction Scriptで十分。最初からDDDにする必要はありません。

Domain Model（DDD）

Domain Model は、業務概念をクラスとして表現し、そこにロジックを集約するスタイルです。DDDはこの方式を体系化した手法で、複雑な業務ドメインを扱う時に威力を発揮します。

class Order {
  place() {
    if (!this.user.isActive) throw new InactiveUserError()
    if (this.items.isEmpty()) throw new EmptyOrderError()
    this.status = OrderStatus.Placed
    return new OrderPlacedEvent(this.id)
  }
}

ロジックが Order クラス内に集約されるため、「注文を出すとはどういうことか」がコード1箇所を読むだけで分かります。テストも書きやすく、業務ルールが増えても秩序を保てます。

DDDの戦術的パターン

DDDでは、ドメインモデルを構築するための戦術的パターンが整理されています。これらを知っておくと、複雑なビジネスロジックを整理された構造で表現できます。

パターンは「必要になってから導入すればよい」最初から全部使う必要はありません。

Value Objectの効用

Value Object は、プリミティブ型ではなく「意味のある型でドメインを表現」するパターンです。「金額」を number ではなく Money クラスで、「メール」を string ではなく Email クラスで表現することで、業務概念を型システムに昇格させます。

❌ sendMoney(amount: number, currency: string)
   → 引数の順序を間違えても検知できない

✅ sendMoney(amount: Money)
   → Money = amount + currency をまとめて持つ

❌ if (email.includes('@'))
   → 毎回バリデーションが必要

✅ Email.parse(str)
   → 不正値は生成時に弾くので、以降は安全

プリミティブ型を使い回す設計は「プリミティブ強迫症」（Primitive Obsession）と呼ばれるアンチパターンです。

Money や Email のようなValue Objectは規模によらず有効。プリミティブ強迫症は初期から意識する価値があります。

集約（Aggregate）

集約は、複数のEntity・Value Objectを「整合性を保つ単位」としてひとまとめにしたものです。集約の内部では強整合を保ち、集約間は結果整合にするのが設計の基本です。

[Order集約]
  ├─ Order（集約ルート）
  ├─ OrderItem[]
  └─ ShippingAddress

集約を跨ぐ更新は原則禁止
 → 他集約に影響を与えるならDomainEvent経由で通知

設計原則は以下の通りです。

• 集約は小さく保つ（大きな集約は競合とロックの温床）
• 集約外への参照はIDのみ（オブジェクト直接参照を避ける）
• 集約の更新は集約ルート経由

集約境界を適切に引けるかがDDDの最大の難所。ここが失敗すると全体が破綻します。

戦略的DDD

DDDには戦術的パターン以上に重要な戦略的DDDの概念があります。これは「コードを書く前に業務の境界を発見する」ことに焦点を当てた思想で、多くのプロジェクトで軽視されがちですが、実は本当に価値があるのはこちらです。

同じ「顧客」という言葉でも、営業部門では「見込み客」を含み、経理部門では「請求先」を意味するといった違いがあります。この違いを無理に統一せず、「コンテキストごとに別モデルとして扱う」のが戦略的DDDの核心です。

貧血ドメインモデル（アンチパターン）

DDDの形だけ真似て、「データだけ持つクラス + ロジックが全部Service層」という状態になる失敗パターンを「貧血ドメインモデル」（Anemic Domain Model）と呼びます。一見DDDっぽく見えますが、中身はTransaction Scriptと変わりません。

❌ class Order {
     id, status, items    // データのみ
   }

   class OrderService {
     static place(order) {
       // ロジックが全部ここにある
       if (!order.user.isActive) throw ...
       if (order.items.length === 0) throw ...
       order.status = 'placed'
       ...
     }
   }

これはDDDの「業務ロジックは業務オブジェクトに集約する」という本質を失っており、「Transaction Scriptの複雑版」にすぎません。DDDの学習曲線が高い最大の理由でもあります。

「DDDを採用した」の95%は貧血モデル。形ではなく「ロジックの置き場所」を問うのが本質です。

ケース別の選び方

CRUD中心・シンプル業務

Transaction Script。無理にDDDを導入してもクラスが増えるだけで、業務価値は上がりません。

ロジックが複雑・業務が頻繁に変化する領域

Domain Model（DDD）。保険・金融・医療・EC・物流など、業務ルールが多い領域では投資が回収できます。

スタートアップMVP

Transaction Script → 成長後にDDD。最初から完璧な設計を目指すと力尽きます。必要になってから段階的に育てる。

既存レガシーシステムの改善

段階的にDDD化。全てを一度に書き直さず、ボトルネックの業務領域から少しずつドメインモデルに移行します。

ロジックの配置原則

業務ルールは常にドメイン層に置く。これはどのスタイルを採用していても共通の原則です。業務ルールがUI・インフラに漏れると、変更時に複数箇所を修正することになり、矛盾が生じやすくなります。

❌ コントローラで税金計算
❌ フロントエンドで割引計算（バックエンドでも再計算が必要になる）
❌ DBストアドプロシージャに業務ルール

✅ ドメイン層のValue Object / Entityに業務ルールを集約

UI側で同じ計算を「表示目的で再現する」のはOKです。ただしルールの保有者は常にドメイン層です。

業務複雑度×スタイルの実務段階表

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

「最初からDDD」は過剰、「ずっとTransaction Script」は破綻の元。業務の複雑さに合わせて段階的に育てるのが現実解です。

判断の目安は「業務ルール変更の頻度」です。週1回以上ルールが変わる領域（保険・金融・物流・EC）はDDD投資が回収できます。一方、CRUD中心の管理画面は5年以上運用してもTransaction Scriptで十分。Martin Fowlerが2003年に整理した3スタイルの使い分けが今も有効です。

DDDは業務複雑度に見合った時だけ。早すぎる導入はクラス爆発しか生みません。

やってはいけないこと

DDDを採用したプロジェクトで事故る典型を整理します。「形だけパターンを並べても貧血モデルになるだけ」、が共通の失敗です。

2003年のEric Evans “Domain-Driven Design” から20年以上経っても、DDDが難しく感じるのは「技術より業務を学ぶこと」が本質だからです。パターンを覚えるより、業務専門家と会話する時間のほうが重要です。

DDDの本質は業務の言葉でモデルを育てる思想で、戦略的DDDを飛ばしてパターンだけ真似ると失敗します。

AI判断軸

選定の優先順位をまとめると次の通りです。

1. 業務複雑度で選ぶ（CRUDはTransaction Script、複雑業務はDDD）
2. 小さく始めて段階的に育てる（最初からDDD全適用は過剰設計）
3. 業務概念を型に昇格（Value Object / Aggregate / Ubiquitous Language）
4. 貧血モデルを避ける（ロジックはドメイン層に集約）

DDDの用語整理がAIへのドメイン知識伝達を助ける

ユビキタス言語（開発者と業務担当が共通で使う用語体系）がコード内の型名・メソッド名に反映されていれば、AIはドメインの意図を理解した上でコードを書けます。「注文」「配送」「請求」がコード上でOrder・Shipment・Invoiceとして型定義されていれば、AIはこれらの関係性を正確に把握できます。

CRUDアプリでは過度な抽象化がAIの足を引っ張る

業務ルールが少ないCRUDアプリにDDDのフル装備（Aggregate・Repository・Domain Event等）を適用すると、AIに修正を頼む際に不要な抽象レイヤーを理解させる必要があり、かえって効率が落ちます。業務複雑度に見合ったシンプルな構造の方がAI活用の効率は高いです。

「Transaction Scriptを2ファイルに分割しただけ」（業界事例）

参画したECサイトの案件で、Order クラスは id と status と items だけを持ち、「注文を確定する」「キャンセルする」「返金する」といった処理は全て OrderService の静的メソッドに並んでいた、という事例があります。レビュー会で「これはDDDではなく、Transaction Scriptを2ファイルに分割しただけです」と指摘された、という話が聞かれます。

過去のプロジェクトで、order.place() と書けない Order クラスを書いてしまい、レビューで「このOrderはただのデータクラスで、業務は語れていない」と指摘される経験はDDDを学び始めた多くのエンジニアが通る道です。「DDDを採用した」と言いながら貧血モデルになっているプロジェクトは極めて多い。

形だけパターンを並べても、ロジックがドメインオブジェクトに宿っていなければDDDではない。order.place() が書けないコードは、まだオブジェクトではなくデータの入れ物です。

決めるべきこと — 自分のプロジェクトでの答えは？

以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• ドメインロジックの記述スタイル（Transaction Script / DDD / 折衷）
• Value Object をどの範囲で採用するか
• 集約の境界定義（Bounded Contextの設計）
• Domain Event / イベント駆動アーキテクチャの採用有無
• DDD戦術的パターンのうちどれを採用するか
• Ubiquitous Languageの文書化と更新ルール

この記事に関連する記事

まとめ

本記事はドメインロジックについて、Transaction Script vs DDD・Value Object・集約・戦略的DDDまで含めて解説しました。如何だったでしょうか。

業務複雑度に見合ったスタイルを選び、業務概念を型に昇格させる。これがAI時代も含めた2026年のドメインロジック設計の現実解です。

次回は命名とコード規約（命名原則・Linter/Formatter・PRレビュー・CODEOWNERS）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は Martin Fowler - Domain Driven Design も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。