🍡

ドメイン駆動設計(DDD) における用語のまとめ

に公開

ドメイン駆動設計(DDD)の基本用語まとめ

ドメイン駆動設計(DDD:Domain-Driven Design)は、複雑なビジネスのルールや仕組みをソフトウェアで正しく表現するための考え方です。

今回の記事では、DDDでよく使われる用語を、まとめていきたいと思います。

DDDの基本用語一覧

用語 説明
ドメイン(Domain) ソフトウェアが扱う「問題のある分野」。ビジネス全体 ECサイトなら「商品を売る」という世界そのもの。
サブドメイン(Subdomain) ビジネスの全体的なドメイン(領域)を意味のある小さな単位に分割したもの 商品の追加・編集・削除など
モデル(Model) ドメインをわかりやすく整理した「考え方」や「設計」。 商品や注文の関係、ルールなど。
ユビキタス言語(Ubiquitous Language) 開発者とビジネスの人が共通して使う言葉。コードにも登場する。 「カート」「購入」「在庫切れ」など。みんなが同じ意味で使う。
エンティティ(Entity) 一意のIDを持つオブジェクト。時間がたっても「同じもの」として扱う。 ユーザー、注文など。IDがあれば中身が変わっても同じものとわかる。
値オブジェクト(Value Object) IDを持たないただの値の集まり。中身が同じなら同一とみなす。 住所、金額、名前など。
集約(Aggregate) 関連するエンティティや値オブジェクトのまとまり 「注文(Order)」という集約には、注文の明細や支払い情報が入る。
集約ルート(Aggregate Root) 集約の入り口となるエンティティ。他からはこれ経由でしかアクセスできない。 「注文」の集約ルートが「注文エンティティ」。
リポジトリ(Repository) 集約を保存・取得するための窓口。DBとのやりとりを担当。 「注文をDBから探してくる」役割のクラス。
ドメインサービス(Domain Service) エンティティにも値オブジェクトにも属さない、ビジネスルールの処理を担う 「送料の計算」「在庫の確認」など、複数エンティティをまたぐ処理。
アプリケーションサービス(Application Service) ユースケース単位の処理を行う。ドメインオブジェクトを使って外から命令する。 「注文する」などの処理をまとめるサービス層。
ファクトリ(Factory) エンティティや集約を正しい形で作るためのもの。 「新しい注文を作る処理」をまとめたクラス。
ドメインイベント(Domain Event) ドメインの中で「何かが起きた」という事実を表す。 「注文が確定された」「商品が発送された」など。
境界づけられたコンテキスト(Bounded Context) モデルの意味やルールが一貫して通じる境界。大規模システムでは複数できる。 「注文」「会計」「配送」などで別のモデルにする。
コンテキストマップ(Context Map) 複数の境界づけられたコンテキストの関係性を示す図や設計。 チームごとの担当領域ややりとりの整理。

覚えておきたいポイント

  • ドメイン=世界観(ビジネスの現場で起きていること)
  • モデル=その世界を表す地図や設計図
  • ユビキタス言語=みんなで使う共通の単語帳
  • ユビキタス言語を使用する目的は、ビジネス側の頭の中の知識や考え方をわかりやすく整理するため。
  • 境界づけられたコンテキストによってユビキタス言語の定義が完成する。ユビキタス言語が通用する範囲は、境界づけられたコンテキストの内部に限定される。
  • エンティティと値オブジェクトの違い
  • 値オブジェクトが等しいかどうかは、値が同じかどうかで判定。
  • サブドメインは3種類ある
  • サブドメインとは、「強く関係し合うユースケースや概念(モデル)の集まり」
  • ドメインモデルとは、事業活動を表現するオブジェクトモデル。
  • 集約値オブジェクトは、ドメインモデルを実装するための部品
  • 集約を実装するときはユビキタス言語を厳密に反映することが必要
  • 業務データの一貫性を保証できる限り、集約はできるだけ小さく設計する。

サブドメインは3種類ある

サブドメインの種類 特徴
コアドメイン ビジネスの中心、差別化の要 レコメンド機能、学習支援アルゴリズム
支援サブドメイン コアを支えるが直接は差別化しない ユーザー管理、問い合わせ機能
汎用サブドメイン 業種共通、再利用可能な一般機能 メール通知、ログ記録

エンティティと値オブジェクトの違いまとめ

比較項目 エンティティ(Entity) 値オブジェクト(Value Object)
IDの有無 ある(必須) ない
同一性(Identity) IDが同じなら「同じもの」として扱う 値が全く同じなら「同じ」とみなす
使いどころ ユーザー、注文、商品などの「個別の存在」 住所、金額、名前などの「ただの情報」
変化 状態が変わることがある(例:名前変更) 基本的に不変。変えたければ作り直す
永続化(DB保存) IDで保存・更新される 値としてまとめて保存される
設計の目的 一意な存在を識別・追跡すること 値の集合を表し、再利用・比較しやすくする

例で理解する

エンティティの例

  • User(ユーザー):id = 1 のユーザーは、名前やメールアドレスが変わっても 同じ人 として扱う。
  • Order(注文):注文の内容が変わっても、IDが同じなら 同じ注文

値オブジェクトの例

  • Address(住所):"東京都港区1-2-3" という情報自体に意味があり、IDは不要。
  • Money(金額):500円 という値があれば、それだけで十分。

判断のポイント

  • 「これってIDがないと困る?」→ エンティティ
  • 「これって値だけで意味が通じる?」→ 値オブジェクト
  • 「中身が変わると困る?」→ エンティティ
  • 「同じ中身なら区別いらない?」→ 値オブジェクト

まとめ

  • エンティティ=個別に追跡したいもの
  • 値オブジェクト=値として比較できればよいもの

どちらを使うかは「その情報がビジネス的にどう扱われるか」で判断する。


まとめ

  • 「この情報はIDが大事?」→ エンティティ
  • 「これは単なる値?」→ 値オブジェクト
  • 「まとまったルールや関係がある?」→ 集約
  • 「DBから集約を取得したい」→ リポジトリ
  • 「ルールをまたいだ動作をしたい」→ サービス
  • 「なにかが起きたことを伝えたい」→ ドメインイベント

Discussion