DDD on 設計で、迷わなくなるために | 奥田智紘

ワイヤーフレームからドメイン設計が進んだ話

Wed, 18 Mar 2026 11:00:00 +0900

はじめに
ドメイン設計だけでは埋まらない違和感
ワイヤーフレームを作って起きた変化
ワイヤーフレームは見た目のためではない
まとめ
おわりに

はじめに

最近、アプリ開発の中で「ワイヤーフレーム」を使い始めたところ、思いがけずドメイン設計が大きく前進しました。

ワイヤーフレームとは、 Figma などを使って作る UI デザインの一種です。
ただし、色やフォントサイズなどの細かい UI にはこだわりません。
ボタンや入力欄であることがわかれば良いという程度のラフな UI デザインのことを言います。

もともとドメイン駆動で設計を進めていたのですが、どうしても「抜け」や「曖昧さ」が残る感覚があり、手応えが弱い状態が続いていました。

しかし、ワイヤーフレームを作り始めたことで、その状況が一変しました。

この記事では、 ワイヤーフレームがどのようにドメイン設計を補完し、加速させたのかを整理してみます。

ドメイン設計だけでは埋まらない違和感

ドメイン設計を進めていると、以下のような状態に陥ることがありました。

ユースケースはある程度整理されている
エンティティや値オブジェクトも定義できている
しかし「本当にこれで使えるのか？」という違和感がある

つまり、構造はあるが、実感がない状態です。

このとき不足していたのは、「ユーザーがどう操作するか」という視点でした。

ワイヤーフレームを作って起きた変化

試しにワイヤーフレームを作り始めたところ、明確な変化がありました。

1. ユーザーの行動が具体化される

ワイヤーフレームでは「画面上で何をするか」を考える必要があります。

どこで入力するのか
どの順番で操作するのか
何を確定とみなすのか

これにより、ユースケースが単なる文章ではなく、操作として具体化されました。

2. 必要なデータと制約が見えてくる

操作を具体的にすると、自然と以下が見えてきます。

この画面では何のデータが必要か
この操作はどんな条件で許されるのか

ここで重要なのが、 不変条件（インバリアント） です。

例えば、口座振替管理アプリなら、

支払い元は必ず 1 つである
振替は「元 → 先」の関係を持つ
不正な組み合わせは作れない

など、これらはドメイン設計だけでも定義できますが、ワイヤーフレーム上で「操作」として考えることで、一気に現実味を帯びます。

3. ドメイン設計の「抜け」が露出する

ワイヤーフレームを作る中で、次のような気づきが頻発しました。

この状態、どうやって作る？
この操作、どのユースケースに対応する？
このデータ、どこに属する？

つまり、ドメイン設計で曖昧だった部分が強制的に表に出てくるのです。

DDDで「集約はIDで参照する」とはどういう意味か

Thu, 12 Mar 2026 19:00:00 +0900

オブジェクト参照の場合
ID参照の場合
違いを整理
- オブジェクト参照
- ID参照
もう一つ重要な違い：イベント駆動に拡張できる
- Application Service
イベントの定義
EventBusの簡易実装
イベントハンドラ
ハンドラ登録
イベントの流れ
まとめ

ドメイン駆動設計（DDD）では、次のようなルールをよく目にします。

集約は他の集約を IDで参照する

しかし、初めてこのルールを見たときに疑問が浮かびます。

ID参照にしても結局 Repository.find(id) で取得できるのでは？
それなら普通のオブジェクト参照とあまり変わらないのでは？

この記事では、このルールの意味を 実際のコードで比較しながら説明します。

オブジェクト参照の場合

まず、他の集約を オブジェクトとして直接持つ設計を見てみます。

Order

class Order(
 val id: OrderId,
 val user: User
) {

 fun place() {
 // 注文処理
 user.upgradeToPremium()
 }
}

tips : place という単語には、注文を出す / 発注するという意味があります。

User

class User(
 val id: UserId,
 var plan: Plan
) {

 fun upgradeToPremium() {
 plan = Plan.PREMIUM
 }
}

アプリケーションサービス

fun placeOrder(orderId: OrderId) {

 val order = orderRepository.find(orderId)

 order.place()

 orderRepository.save(order)
}

ここで起きていることを図にすると次のようになります。

一つの集約にまとめるべきか、別の集約に分けるべきかの判断基準（DDD）

Thu, 12 Mar 2026 18:00:00 +0900

1. 不変条件を同時に守る必要があるか（最重要）
- 例
- 別集約になる例
2. ライフサイクルが一緒か
- 例
- 別集約の例
3. 集約は他の集約をIDで参照する
4. 同時に更新されるか
- 例
5. 集約は小さく保つ
まとめ

ドメイン駆動設計（DDD）で設計をしていると、次のような疑問に必ずぶつかります。

このエンティティは同じ集約に入れるべきか？
それとも別の集約として切り離すべきか？

集約の境界は、DDDにおいて非常に重要な設計判断です。この記事では、実務でよく使われる判断基準を整理します。

1. 不変条件を同時に守る必要があるか（最重要）

最も重要な基準は 不変条件（Invariant） です。

「このルールは常に同時に成立している必要があるか？」

YESなら 同じ集約
NOなら 別集約

例

注文と注文明細

Order
└ OrderItem

不変条件

注文の合計金額 = 各注文金額の合計
注文明細の数量 ≥ 1

数量が変われば、注文全体の合計金額は変わります。つまり、これらは 常に同時に成立している必要があります。そのため Order と OrderItem は 同じ集約になります。

別集約になる例

Order
Inventory (在庫)

ルール

注文が確定したら在庫を減らす

この処理は

注文確定
在庫更新

の2つの処理に分かれます。

これらは 同時トランザクションでなくても問題ないため

Order集約
Inventory集約

と分けます。

2. ライフサイクルが一緒か

次に考えるのは ライフサイクルです。

「一緒に生まれて一緒に消えるか？」

YES → 同じ集約
NO → 別集約

例

Order
└ OrderItem

OrderItem は

ドメイン設計テンプレート

Wed, 11 Mar 2026 10:00:00 +0900

このドキュメントは、DDD（ドメイン駆動設計）に基づいて、ソフトウェアを設計するためのテンプレートです。

上から順番にテンプレートを埋めていくことで、 DDD に基づいたドメイン周りの設計がスムーズに行えるように作っています。

1. システム概要
2. ユースケース
3. ユビキタス言語
4. エンティティ候補
5. 不変条件（Invariant）
6. 状態遷移
- 【例】TransferRelation
  - 状態
  - 状態遷移
7. 集約設計
8. ドメインサービス
9. リポジトリ
10. ユースケース設計

1. システム概要

システムの目的

このシステムは何を解決するものか。

【例】

フリーランスの固定費を管理する
口座振替の関係を可視化する

対象ユーザー

このシステムのユーザー。

【例】

個人
フリーランス
企業

解決したい課題

【例】

固定費の支払い関係が分かりにくい
口座振替の全体構造を把握できない

2. ユースケース

ユーザーがシステムで行う操作を列挙する。

ドメイン設計テンプレート（補強版）

Wed, 11 Mar 2026 10:00:00 +0900

このドキュメントは、ドメイン設計テンプレートに以下の項目を加えた補強版となっています。

4.境界コンテキスト
5.コンテキストマップ
7.値オブジェクト
12.ドメインイベント
15.集約境界図
16.不変条件の責任

1. システム概要
2. ユースケース
3. ユビキタス言語
4. 境界コンテキスト
5. コンテキストマップ
6. エンティティ候補
7. 値オブジェクト
8. 不変条件（Invariant）
9. 状態遷移
- 【例】TransferRelation
  - 状態
  - 状態遷移
10. 集約設計
11. ドメインサービス
12. ドメインイベント
イベント詳細
- 【例】TransferRelationCreated
  - 発生タイミング
  - ペイロード
13. リポジトリ
14. ユースケース設計
15. 集約境界図（Aggregate Boundary）
- 【例】TransferRelation
16. 不変条件の責任（Invariant Responsibility）

1. システム概要

システムの目的

このシステムは何を解決するものか。

DDDにおける「集約」「ドメインサービス」「ユースケース」の違い

Tue, 10 Mar 2026 16:00:00 +0900

DDDにおける「集約」「ドメインサービス」「ユースケース」の違い
まず結論
集約（Aggregate）
ドメインサービス
ユースケース（Application Service）
ドメインロジックをどこに置くか
状態を持つドメインサービスはどうなるか
- ケース1：新しいドメイン概念が生まれた
- ケース2：一時的な処理状態
判断のための質問
よくある失敗
まとめ

DDDにおける「集約」「ドメインサービス」「ユースケース」の違い

DDD（ドメイン駆動設計）を学び始めると、多くの人が次の疑問にぶつかります。

集約とドメインサービスは何が違うのか
ユースケースはどこまで責任を持つのか
ドメインロジックはどこに書くべきなのか

この記事では、この3つの概念を整理しながら、ドメインロジックをどこに置くべきかの判断基準を解説します。

まず結論

3つの役割は次のように整理できます。

集約（Aggregate）

ドメインの状態を持つ
不変条件を守る
ドメインモデルの中心

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

エンティティに属さないドメインロジック
複数の集約にまたがる処理

ユースケース（Use Case / Application Service）

ユーザー操作を実現する手順
ドメインモデルを組み合わせる

依存関係は次のようになります。

UI
↓
UseCase
↓
DomainService
↓
Aggregate

重要なルールは 内側の層は外側を知らないこと です。

集約（Aggregate）

集約は 状態と不変条件を守るドメインモデル です。

例として「口座振替」を考えます。

振替関係には次のルールがあります。

振替日は 1〜31
「振替元 + 振替先」が同じ振替関係は 1 つだけ (重複不可)

このルールを守る主体が TransferRelation です。

class TransferRelation(
 val accountId: AccountId,
 val serviceId: ServiceId,
 private var paymentDay: PaymentDay
) {

 fun changePaymentDay(newDay: PaymentDay) {
 paymentDay = newDay
 }

 fun stop() {
 // 状態変更
 }
}

【集約の特徴】

DDDでドメインを設計するときの流れ

Tue, 10 Mar 2026 14:00:00 +0900

DDDでドメインを設計するときの流れ
ドメイン設計の全体の流れ
この記事の前提
1. ユースケースを書き出す
2. ドメイン用語を整理する（ユビキタス言語）
3. エンティティ候補を出す
4. 不変条件を書く
5. 状態遷移を整理する
6. 集約（Aggregate）を決める
7. エンティティの責務を設計する
8. ドメインサービスを定義する
9. リポジトリを定義する
10. 最後にUIを作る
まとめ
この流れで設計する際のテンプレート

DDDでドメインを設計するときの流れ

― 実践的な設計手順 ―

ドメイン駆動設計（DDD）を学び始めると、多くの人が次の疑問を持ちます。

ドメイン設計は何から始めればいいのか
実際の開発ではどのような手順で設計するのか

DDDの本では概念の説明が多く、「実際の設計手順」がはっきりしないことがあります。

この記事では、実務で使える ドメイン設計の具体的な手順 を整理して紹介します。

ドメイン設計の全体の流れ

DDDでドメインを設計する場合、次の順序で進めると整理しやすくなります。

ユースケースを書き出す
ドメイン用語を整理する（ユビキタス言語）
エンティティ候補を出す
不変条件を書く
状態遷移を整理する
集約（Aggregate）を決める
エンティティの責務を設計する
必要ならドメインサービスを作る
リポジトリを定義する
最後にUIを設計する

重要なのは UIから設計を始めないこと です。

DDDでは、基本的には、

ユースケース → ドメイン → UI

という順序で設計します。

実際には、一度でバシッと決められるわけではないため、ドメインを設計しているときに、ユースケースに戻るなど、各プロセス間を何度も行ったり来たりします。

この記事の前提

この記事では、口座振替管理アプリの開発を想定して、設計の流れを説明してきます。

振替元と振替先をユーザーが紐づけるメモアプリを想像してください。

1. ユースケースを書き出す

最初に、システムでユーザーが行う操作を書き出します。

ポイントは UIではなく行動を書くこと です。

Aggregate Root とは

Thu, 12 Feb 2026 10:00:00 +0900

Aggregate Root とは

Aggregate Root とは

はじめに

DDD（Domain-Driven Design）の文脈で頻繁に登場する Aggregate Root（集約ルート） について解説していきます。

本記事では、

Aggregate / Aggregate Root とは何か
なぜこの概念が必要なのか
設計時の注意点

を整理します。

Aggregate（集約）とは

Aggregate とは、

関連する複数の Entity / Value Object を
一つのまとまり（整合性の境界） として扱う

DDD の設計単位です。

重要なのは、

Aggregate は「常に一貫した状態を保つべき単位」

という点です。