ドメイン駆動設計（DDD）入門：ビジネスロジックを中心に据えたソフトウェア設計の手法

2025年4月14日

複雑な業務ロジックを持つアプリケーションを効率よく、かつ正確に開発するには、ビジネスそのものを深く理解し、それをソフトウェアの構造に反映させることが重要です。

そこで注目されるのが、ドメイン駆動設計（Domain-Driven Design, DDD）です。本記事ではDDDの基礎から、実践的な設計手法までを包括的に解説します。

1. DDDとは何か？

ドメイン駆動設計は、エリック・エヴァンスによって提唱されたソフトウェア設計のアプローチです。

システム開発における「ドメイン」とは、ソフトウェアが対象とするビジネス領域のことを指し、DDDではこのドメインを中心にソフトウェアを設計します。

DDDの目的：

ビジネスの本質を正しく捉える
ソフトウェアと業務知識の乖離をなくす
保守性・拡張性に優れた構造をつくる

2. DDDの重要性

2.1 ビジネスと技術の架け橋

ユビキタス言語により、ドメインの専門家と開発者が共通の言語で議論できるため、認識のズレが減ります。

2.2 保守性と拡張性の向上

ドメインモデルを中心に設計することで、責務が明確になり、変更の影響範囲を限定できます。

2.3 複雑なロジックの整理

複雑なビジネスルールをコードにそのまま反映することで、システム全体の理解と改善が容易になります。

3. DDDの主要概念

3.1 ユビキタス言語（Ubiquitous Language）

ビジネスの用語を開発者・専門家の間で統一し、コード、設計書、ドキュメントすべてで同じ言葉を使います。

例：ECサイトの「注文」はコード上でもOrderとして扱う

3.2 エンティティ（Entity）

一意のIDを持ち、ライフサイクルを通じて同一性を保持するオブジェクト。

class Order
  attr_reader :id, :items

  def initialize(id, items)
    @id = id
    @items = items
  end
end

3.3 値オブジェクト（Value Object）

属性の集合で識別されるオブジェクト。変更されることを前提とせず、等価性は属性値で判断されます。

class Address
  attr_reader :street, :city, :zip_code

  def initialize(street, city, zip_code)
    @street = street
    @city = city
    @zip_code = zip_code
  end
end

3.4 集約（Aggregate）

関連するエンティティと値オブジェクトの集合で、一貫性の単位。外部からは「集約ルート」のみが参照されます。

例：「注文（Order）」は「注文アイテム（OrderItem）」の集約ルート。

3.5 リポジトリ（Repository）

集約の永続化・取得を担当する抽象的なインターフェース。

class OrderRepository
  def find_by_id(id)
    # データベースからOrderを取得
  end

  def save(order)
    # Orderを保存
  end
end

3.6 ドメインサービス（Domain Service）

エンティティに属さないビジネスロジックを表現する。

class PaymentService
  def process_payment(order, payment_info)
    # 支払い処理のロジック
  end
end

4. DDDの実践方法

4.1 ドメインモデリングの実施

ドメインの専門家と開発者で共同作業
ユビキタス言語を文書化
主要エンティティ・値オブジェクト・集約の抽出

4.2 レイヤードアーキテクチャの導入

DDDでは以下の4層構造が基本です：

ドメイン層：ビジネスルールの中心
アプリケーション層：ユースケースの調整と実行
インフラ層：DBや外部APIとの接続
UI層：WebインターフェースやAPIコントローラ

4.3 境界づけられたコンテキスト（Bounded Context）

ドメイン全体を単一で扱わず、機能ごとにコンテキストを分離する。

例：「注文管理」「在庫管理」「顧客管理」など、それぞれを独立したコンテキストとし、明確な境界を設ける。

4.4 CQRS（Command and Query Responsibility Segregation）

データの更新（Command）と参照（Query）を分離することで、システムの柔軟性とパフォーマンスを向上させます。

Command：状態を変更する操作（例：注文作成）
Query：状態を読み取る操作（例：注文履歴の取得）

5. まとめ

DDDは、ビジネスの構造をソフトウェアに反映するための強力な設計アプローチ
ユビキタス言語により、開発者と業務担当の共通認識が得られる
エンティティ、値オブジェクト、集約、ドメインサービスなどの概念を使い分けて整理
レイヤードアーキテクチャやCQRSによって、保守性・スケーラビリティを両立

最初は部分的な適用からでも構いません。「ドメインを中心に設計する」という意識を持つだけでも、システムの質は大きく変わります。

参考リソース

DDD Community
書籍：『エリック・エヴァンスのドメイン駆動設計』
書籍：『実践ドメイン駆動設計』

ドメイン駆動設計を取り入れて、ビジネスに強く、変更に強いソフトウェアを実現していきましょう！