Zenn
Open6

DDD (ドメイン駆動設計・Entity) について🌟

設計
DB
ドメイン
ドメインモデル
ドメイン駆動設計
まさぴょんまさぴょん

DDD、Domain(ドメイン)とは？

ドメイン駆動設計（Domain-Driven Design、DDD）は、ソフトウェア開発におけるアプローチの一つで、複雑なビジネス要件を効果的に反映するソフトウェアを構築することを目的としています。DDDは、ソフトウェアの設計と開発をビジネスのドメイン（領域）に密接に結びつけ、ビジネスの専門家と開発者の間のコミュニケーションを強化します。

ドメインとは、特定の知識、活動、または影響の領域を指します。ビジネスのコンテキストでは、ドメインは企業が直面する問題や課題、そしてそれらを解決するための専門知識を含みます。

DDDの主なコンセプトと要素は以下の通りです：

  • ユビキタス言語（Ubiquitous Language）：開発チームとビジネスの専門家が共有する共通の言語で、誤解やコミュニケーションのギャップを減少させます。
  • エンティティ（Entity）：一意の識別子を持つオブジェクトで、システム内での状態と振る舞いを持ちます。
  • 値オブジェクト（Value Object）：属性によって定義され、一意の識別子を持たない不変のオブジェクトです。
  • アグリゲート（Aggregate）：関連するエンティティと値オブジェクトの集合で、一貫性の境界を形成します。
  • リポジトリ（Repository）：アグリゲートの永続化と取得を扱う抽象化されたストレージメカニズムです。
  • サービス（Service）：特定のエンティティに属さない操作やビジネスロジックをカプセル化します。
  • 境界付けられたコンテキスト（Bounded Context）：ユビキタス言語とモデルの適用範囲を明確に定義することで、大規模なシステムを管理しやすくします。

DDDを適用することで、以下のようなメリットが得られます：

  • ビジネス要件と技術的実装の間のギャップを縮小。
  • 変更に強い柔軟なアーキテクチャの構築。
  • チーム間のコミュニケーションの向上。
  • 複雑なドメインロジックの整理と理解の促進。

要するに、DDDはビジネスの深い理解に基づいたソフトウェア設計を促進し、価値あるソリューションを提供するための指針となります。

まさぴょんまさぴょん

DDD と Domain の具体的な説明

ドメイン駆動設計（DDD）は、ソフトウェアの設計をビジネスのドメイン（領域）に焦点を当てて行う手法です。ここでは、ユーザー（User）、ギルド（Guild）、ギルドマスター（Guild Master）、**クエスト（Quest）**といったエンティティを例に、DDDとドメインの関係性を説明します。

ドメインの理解

まず、ドメインとは、特定の問題領域やビジネスの活動範囲を指します。例えば、オンラインゲームの開発を考えると、ゲーム内のプレイヤー管理、ギルドシステム、クエストシステムなどがドメインになります。

DDDの適用

DDDでは、以下のような要素を用いてドメインをモデル化します。

1. エンティティ（Entity）

エンティティは、一意の識別子を持ち、そのライフサイクルを通じて識別されるオブジェクトです。

  • ユーザー（User）：プレイヤー個々人を表し、一意のID、名前、レベル、経験値などの属性を持ちます。
  • ギルド（Guild）：プレイヤーの集まりであり、一意のID、ギルド名、設立日、メンバーリストなどの属性を持ちます。
  • ギルドマスター（Guild Master）：ギルド内で特別な権限を持つユーザーであり、ギルドの管理を行います。
  • クエスト（Quest）：プレイヤーが挑戦できるミッションで、一意のID、目的、報酬、難易度などの属性を持ちます。

2. 値オブジェクト（Value Object）

値オブジェクトは、属性によって定義され、一意の識別子を持たない不変のオブジェクトです。

  • 座標（Coordinate）：ゲーム内の位置情報を表し、X、Y、Zの座標値で定義されます。
  • 報酬（Reward）：クエストの完了時に得られるアイテムや経験値などを表します。

3. アグリゲート（Aggregate）

アグリゲートは、関連するエンティティと値オブジェクトの集合で、一貫性の境界を形成します。

  • ギルドアグリゲート：ギルドをルートエンティティとし、ギルドマスター、メンバー、ギルド資産などを含みます。
  • クエストアグリゲート：クエストをルートエンティティとし、目的地、報酬、関連するモンスターなどを含みます。

4. リポジトリ（Repository）

リポジトリは、エンティティの永続化と取得を扱う抽象化されたストレージメカニズムです。

  • ユーザーリポジトリ：ユーザー情報の保存や検索を行います。
  • ギルドリポジトリ：ギルドとそのメンバー情報を管理します。
  • クエストリポジトリ：クエストデータの保存と取得を行います。

5. サービス（Service）

サービスは、エンティティに属さないビジネスロジックをカプセル化します。

  • ギルド管理サービス：ギルドの作成、解散、メンバーの招待や除名などの操作を提供します。
  • クエストマッチングサービス：プレイヤーに適切なクエストを提案します。

6. ユビキタス言語（Ubiquitous Language）

開発チームとビジネスの専門家が共有する共通の言語です。

  • 用語の統一：全員が「ユーザー」はプレイヤー個人、「ギルド」はプレイヤーの集団、「ギルドマスター」はギルドの管理者、「クエスト」はミッションという認識を共有します。

7. 境界付けられたコンテキスト（Bounded Context）

ドメインモデルやユビキタス言語の適用範囲を明確に定義します。

  • プレイヤー管理コンテキスト：ユーザーの登録、ログイン、プロフィール編集などを扱います。
  • ギルドコンテキスト：ギルドの作成、管理、メンバーシップなどを扱います。
  • クエストコンテキスト：クエストの生成、配信、進行管理を扱います。

DDDとドメインの関係性のまとめ

  • ドメインモデルの構築：ユーザー、ギルド、ギルドマスター、クエストといったエンティティを通じて、ゲーム内のビジネスロジックをモデル化します。
  • 一貫性の維持：アグリゲートを用いて、データの整合性と一貫性を保ちます。例えば、ギルド内のメンバー追加や削除はギルドアグリゲート内で管理されます。
  • ビジネスロジックの明確化：サービス層でビジネスルールを実装し、エンティティの責務を明確に分離します。
  • コミュニケーションの効率化：ユビキタス言語により、開発者とビジネスの専門家（例えばゲームデザイナーやプロデューサー）が共通の理解を持ち、要件定義や仕様策定がスムーズになります。
  • モジュール化とスケーラビリティ：境界付けられたコンテキストにより、システムをモジュール化して開発しやすくし、将来的な機能追加や変更にも柔軟に対応できます。

具体的な例

  • ギルドへのユーザー参加：

    • ユビキタス言語：ユーザーがギルドに「参加する」というアクション。
    • エンティティ：ユーザーエンティティとギルドエンティティが関与。
    • サービス：ギルド管理サービスが参加リクエストを処理。
    • リポジトリ：ギルドリポジトリがギルドのメンバーリストを更新。

  • クエストの完了と報酬の受け取り：

    • ユビキタス言語：ユーザーがクエストを「完了し」、「報酬を受け取る」。
    • エンティティ：ユーザーエンティティとクエストエンティティが関与。
    • サービス：クエストサービスが進行状況を管理し、報酬を付与。
    • 値オブジェクト：報酬は値オブジェクトとして定義。

メリット

  • ビジネス要件との整合性：ドメインモデルがビジネスロジックを直接反映するため、要件変更に強い設計となります。
  • チーム間の協力強化：ユビキタス言語により、開発者とビジネス側のコミュニケーションが円滑になります。
  • 保守性と拡張性：境界付けられたコンテキストにより、システムがモジュール化され、機能の追加や変更が容易になります。

まとめ

DDDを通じて、ユーザー、ギルド、ギルドマスター、クエストといったエンティティを中心にドメインを深く理解し、ソフトウェアモデルに反映することで、ビジネス価値の高いシステムを構築できます。これにより、複雑なビジネスロジックを効果的に管理し、開発プロセス全体の効率化と品質向上を実現できます。

まさぴょんまさぴょん

ドメイン (Entity) とDBのテーブルの関係について

DDD では、ドメイン (Entity) が、そのままDBのテーブルになる認識ですが、あっていますか？

いいえ、ドメイン駆動設計（DDD）において、ドメインのエンティティがそのままデータベースのテーブルになるという認識は必ずしも正しくありません。

ドメインモデルとデータベースモデルの分離

  • ドメインモデル：ビジネスロジックやビジネスルールを表現するためのモデルであり、ソフトウェアが解決しようとする問題領域（ドメイン）に焦点を当てています。
  • データベースモデル：データの永続化や効率的な保存・取得を目的としたモデルであり、技術的な要件やパフォーマンスに重きを置きます。

DDDでは、**ドメインモデルとデータベースモデルは別の関心事（関心の分離）**として扱われます。つまり、ドメインエンティティとデータベースのテーブルが一対一で対応する必要はありません。

なぜ一致しないのか？

  1. 設計の目的が違う：

    • ドメインモデルはビジネスロジックの表現に最適化されています。
    • データベースモデルはデータの永続化とパフォーマンスに最適化されています。

  2. データの整合性がずれるリスクを低減：

    • ドメインモデルをデータベース構造に密接に結びつけると、データベースの変更がドメインロジックに直接影響を及ぼし、保守性が低下します。

  3. 技術的な要件への対応：

    • データベースの正規化やインデックス設計、クエリの最適化など、技術的な要件に応じてデータベースモデルを調整する必要があります。

リポジトリパターンの役割

  • リポジトリは、ドメインエンティティとデータベースモデルの間の変換やマッピングを担当します。
  • これにより、ドメインモデルはデータベースの実装から独立し、ビジネスロジックに集中できます。

具体的な例

  • ユーザーエンティティ：ビジネス上のユーザーの振る舞いや状態を表現します。
  • ユーザーテーブル：データベース内でユーザー情報を保存するための構造です。
  • 差異の可能性：エンティティでは複雑なオブジェクトや値オブジェクトを含むが、データベースではこれらをフラットなテーブル構造に変換する必要がある場合があります。

メリット

  • 柔軟性の向上：ドメインモデルがデータベースの変更に影響されにくくなります。
  • テスト容易性：ドメインロジックを独立してテストしやすくなります。
  • ビジネスロジックの明確化：データ永続化の詳細から解放され、ビジネスロジックに専念できます。

まとめ

ドメイン駆動設計では、ドメインモデルとデータベースモデルを明確に分離することで、ビジネスロジックの表現力とシステムの柔軟性を高めます。そのため、ドメインエンティティがそのままデータベースのテーブルになるという認識は、DDDの原則から外れています。