実践アプリケーション設計 ③ドメイン駆動設計

2025年度リクルート エンジニアコース新人研修の講義資料です

Transcript

1. 実践アプリケーション設計 ③ドメイン駆動設計 プロジェクト推進部 藤本 毅 2025年7月17日
2. (C) Recruit Co.,Ltd. All rights reserved. 2 講師自己紹介 【名前】 藤本 毅（フジモト タケシ） 【所属】 プロジェクト推進部 【経歴】 IT企業、常駐型開発会社、スタート アップ支援会社、通信キャリア等を 通してB2BからB2Cまで（官公庁シ ステムからチャットサービス、広告、 音楽、エンタメ、旅行、金融、飲食、 HR等）様々なシステムの開発に携 わる
3. (C) Recruit Co.,Ltd. All rights reserved. 3 当資料の目的 架空のECサイト（『R書店』）を題材にしたアプリ ケーションの設計・実装をベースに、ドメイン駆動 設計の概要を解説する。また実践的なリファクタリ ング課題を通して、トランザクションスクリプトと の違いを体感してもらう
4. (C) Recruit Co.,Ltd. All rights reserved. 4 目次 1. ドメイン駆動設計とは 2. ドメインとは 3. 境界づけられたコンテキスト 4. ドメイン駆動設計のアプリケーションの構成 5. ドメイン駆動設計のアーキテクチャ 6. 事業価値をもたらすソフトウェア開発に必要なこと 7. 基礎知識の確認テスト 8. ドメインモデリング 9. R書店の設計のユースケースと ビジネスフロー 10.ドメイン駆動設計におけるデータベース設計
5. (C) Recruit Co.,Ltd. All rights reserved. 5 目次 11. サンプルの実装について 12. ドメイン駆動設計の実装に関連した補足 13. 紛らわしい概念の整理 14. トランザクションスクリプトの実装との比較 15. リファクタリング課題 16. ドメインモデルの改善 17. その他開発手法やアーキテクチャについて 18. ドメイン駆動設計とトランザクションスクリプトとの使い分け 19. 推薦書籍
6. (C) Recruit Co.,Ltd. All rights reserved. 6 1. ドメイン駆動設計とは
7. (C) Recruit Co.,Ltd. All rights reserved. 7 ドメイン駆動設計とは ドメイン駆動設計(Domain-Driven Design, DDD) は、エリック・エヴァンスによって提唱されたソフ トウェア開発と設計の手法 DDDの目的 複雑なビジネスドメインを正しく理解し、 ソフトウェアをビジネス要件に対して柔軟かつ効果 的に対応できるようにすること
8. (C) Recruit Co.,Ltd. All rights reserved. 8 ドメイン駆動設計のメリット ①機能性を高められる これは、役に立つものを作ること、言い換えると 「作ったけど使えない」プロダクトが出来上がるこ とを避けやすい ②保守性を高められる 長期間開発しても機能拡張が容易でありつづけられ る。つまり、「技術的負債でどんどん開発速度が低 下する」状態を避けられやすい。開発者も理解しや すい
9. (C) Recruit Co.,Ltd. All rights reserved. 9 ドメイン駆動設計とデータ中心設計（トランザク ションスクリプト）の比較 データ中心設計では、最初はシンプルであるが、時 間の経過とともに複雑性が一気に増していく。一方 ドメイン駆動設計では時間の経過とともにシステム の維持と進化が容易になる。 引用元：Domain-centric vs data-centric approaches to software development ドメイン駆動設計 データ中止設計（トランザクションスクリプト）
10. (C) Recruit Co.,Ltd. All rights reserved. 10 ドメイン駆動設計の主な特徴 ①ドメイン中心（=ドメインモデル中心）の設計 ドメイン駆動設計では、ソフトウェア開発の中心に ビジネスドメインを置く。開発者はドメインについ て学び、ドメインエキスパート（※後述）と協力 し、ドメインを正確にモデル化することに注力す る。 ➁モデル駆動設計 ドメイン駆動設計では、ドメインモデルを中心とし た設計アプローチを採る。
11. (C) Recruit Co.,Ltd. All rights reserved. 11 ドメイン駆動設計の主な特徴 ③ユビキタス言語 ドメイン駆動設計では、開発にあたってチームやプ ロジェクト全体でユビキタス言語と呼ばれる特別な 共有言語を開発者とドメインエキスパート（※後 述）との間で共有して会話
12. (C) Recruit Co.,Ltd. All rights reserved. 12 2. ドメインとは
13. (C) Recruit Co.,Ltd. All rights reserved. 13 ドメインとは 業務領域を指し、業務知識やルールを含む また、関連するユースケースの集まりともいえる 引用元： https://speakerdeck.com/hidenorigoto/sohutoueashe-ji-nodomein-detamoderingudedomeinwoqu-dong-suru-wodu-nde ドメインの例：ソースコード管理
14. (C) Recruit Co.,Ltd. All rights reserved. 14 ECサイトにおける「注文」 ユースケース観点 例えば以下のように顧客がシステムを通じて目標を 達成するための一連のアクションの定義する。 1. 顧客がログインする 2. 商品を検索する 3. 商品をカートに追加する 4. カートを確認し、チェックアウトする 5. 配送先住所を入力したり、支払い方法を選択し、 注文を確定する 6. 注文確認と完了の通知を受け取る
15. (C) Recruit Co.,Ltd. All rights reserved. 15 ECサイトにおける「注文」 ドメイン（知識）の観点 「ドメインに存在するルール/制約」の観点で整理すると以下 のようになる 顧客: • 氏名、emailアドレス（重複不可）、ステータス（状態）を持つ • 管理者によってステータスが変更される 商品: • 書籍や文具、DVD等、複数の種類がある 注文: • ログインユーザ（顧客）のみ注文が可能 • 顧客情報や商品別の注文明細情報と紐づく • 決済や配送状況によってステータスが変化する
16. (C) Recruit Co.,Ltd. All rights reserved. 16 コアドメインとサブドメイン ドメインはコアドメインとサブドメインで分かれる コアドメイン： 事業的に最も重要で戦略的に不可欠なもの サブドメイン： システム的に必要でありつつもコアドメインではな いもの 「支援サブドメイン」と「汎用サブドメイン」の2 種類に分類される
17. (C) Recruit Co.,Ltd. All rights reserved. 17 支援サブドメイン 「支援サブドメイン」はコアドメインほど重要では ないものの、業務的に特別なものを表す。 例えば、コアドメインの支援を行う独自機能などが 該当
18. (C) Recruit Co.,Ltd. All rights reserved. 18 汎用サブドメイン 「汎用サブドメイン」は、業務的に特別ではない が、システムにおいて必要な箇所(ドメ イン)を表 す。 例えば認証機能やERPやECなど、極端な場合、交換 されたとしても差し支えのな い機能が該当する
19. (C) Recruit Co.,Ltd. All rights reserved. 19 エリック・エヴァンスが唱えたDDDの”原則” エリック・エヴァンスは以下を原則として提唱した エリック・エヴァンスが唱えたDDDの”原則” 1. 「コアドメインに注力する」こと 2. ドメインの実践者とソフトウェアの実践者による創造的 な共同作業を通じて、モデルを探求すること 3. 明示的な境界付けられたコンテキストの内部でユビキタ ス言語を語ること
20. (C) Recruit Co.,Ltd. All rights reserved. 20 3. 境界づけられた コンテキスト
21. (C) Recruit Co.,Ltd. All rights reserved. 21 境界づけられたコンテキスト ビジネスドメインを包括する特定の範囲や境界を定めた 概念で、特定の用語やドメインモデルが一貫した定義で 適用できる範囲や文脈（モデルには必ず境界がある）を 指す。 例：Eコマースシステムの境界づけられたコンテキスト 引用元：https://www.amazon.co.jp/-/en/実践ドメイン駆動設計-ヴォーン・ヴァーノン/dp/479813161X/ref=tmm_pap_swatch_0
22. (C) Recruit Co.,Ltd. All rights reserved. 22 複数のサブドメインにまたがるコンテキスト 境界付けられたコンテキストと各サブドメイン（最 上位のサブドメイン）が1対1で対応しているのが最 も望ましい形式とされるが、ドメインモデルに複数 のサブドメインにまたがる「横断的な一貫性」があ る場合は、該当する複数のサブドメインをもって、 1つの境界づけられたコンテキストとして見なすこ とは可能。
23. (C) Recruit Co.,Ltd. All rights reserved. 23 4. ドメイン駆動設計のアプリ ケーションの構成
24. (C) Recruit Co.,Ltd. All rights reserved. 24 ドメイン駆動設計のアプリケーション 以下のレイヤードアーキテクチャで解説 プレゼンテーション層 アプリケーション層 （ユースケース層） ドメイン層 インフラストラクチャ層 アプリケーションサービス ドメインモデル ファクトリ リポジトリ View Controller
25. (C) Recruit Co.,Ltd. All rights reserved. 25 4-1. プレゼンテーション層
26. (C) Recruit Co.,Ltd. All rights reserved. 26 プレゼンテーション層の役割 • ユーザや外部システムからのリクエスト仕様を定 義し、リクエストを受け取る • バリデーションや入力形式のチェック • ユースケースを実行するためにアプリケーション 層を呼び出す • レスポンス仕様を定義し、レスポンスを返す
27. (C) Recruit Co.,Ltd. All rights reserved. 27 プレゼンテーション層の主な構成要素 • コントローラー （Controller） • ユーザーからの入力（HTTPリクエストなど）を 受け取り、アプリケーション層に処理を橋渡しす る • アプリケーション層から処理結果を受け取り、レ スポンスを返す • ビュー（View） • HTML等の出力形式に変換してユーザ側に表示す る
28. (C) Recruit Co.,Ltd. All rights reserved. 28 4-2. アプリケーション層 （ユースケース層）
29. (C) Recruit Co.,Ltd. All rights reserved. 29 アプリケーション層の役割 • ユースケース（アプリケーションの機能）を実行す るための「オーケストレーション」を担う • ドメイン層から必要なロジックを呼び出す（ドメイ ンオブジェクトを使って必要な処理を組み立てる） • トランザクションの境界を管理する
30. (C) Recruit Co.,Ltd. All rights reserved. 30 アプリケーション層の主な構成要素 • アプリケーションサービス • リポジトリのインターフェース
31. (C) Recruit Co.,Ltd. All rights reserved. 31 4-2-1. アプリケーションサービス (Application Service)
32. (C) Recruit Co.,Ltd. All rights reserved. 32 サービスとは OASIS（コンピュータと通信に関する標準化団体の 一つ）によるとサービスは「1つ以上の機能にアク セスできる仕組みで、規則として定められたイン ターフェースを用いて提供されるもの」と定義され る ※『実践アプリケーション設計②トランザクションスク リプトへの対応』に記載の内容を再掲
33. (C) Recruit Co.,Ltd. All rights reserved. 33 サービスの特徴 「状態」を持たない（ステートレス） • サービスは 内部に状態を持たず、リクエストに 応じて 一連の処理を調整・仲介する オーケストレーション（指揮・調整）が主な責務 • 振る舞いの本質はモデルや他のモジュールに委 ね、サービスはそれらを組み合わせてユースケー スを実現する。 • 「何をするか」はサービス、「どうするか」はモ デルや他のモジュールが担う
34. (C) Recruit Co.,Ltd. All rights reserved. 34 ドメイン駆動設計におけるサービス サービスには、大きく分けて、アプリケーション サービスとドメイン層のドメインサービス（※後 述）の2つが存在する。 いずれも状態を持たないステートレスな「サービ ス」である。
35. (C) Recruit Co.,Ltd. All rights reserved. 35 アプリケーションサービスの役割 (Application Service) • ユーザーの操作やシステムのトランザクション全 体にわたるワークフローやプロセスを調整・管理 （オーケストレーション）する役割を持ち、複数 のドメインオブジェクトやドメインサービスを利 用して、エンドツーエンドのユーザーケース （例：商品購入、アカウント登録）を実行する • ドメインの複雑なビジネスロジックを直接扱うよ りも、ドメイン層のオブジェクト間のインタラク ションや外部アプリケーションとのインテグレー ションを担う
36. (C) Recruit Co.,Ltd. All rights reserved. 36 アプリケーションサービスと ユースケース（UseCase） 「アプリケーションサービス（ApplicationService）」 ではなく「ユースケース（UseCase）」という名前で用 いられることもあるが、どちらもユースケースを実現する ためのモジュールであるため、同義として差し支えない。
37. (C) Recruit Co.,Ltd. All rights reserved. 37 4-3. ドメイン層 （アプリケーションの中核）
38. (C) Recruit Co.,Ltd. All rights reserved. 38 ドメイン層の役割 システムの中核を担い、ドメイン知識を表現する層。 ドメインロジック（ドメインに特化したビジネスロ ジック）を実装する。 ドメイン層の主な構成要素 • ドメインモデル • ファクトリ
39. (C) Recruit Co.,Ltd. All rights reserved. 39 4-3-1. ドメインモデル
40. (C) Recruit Co.,Ltd. All rights reserved. 40 モデルとは • 現実のモノや出来事を用途を限定して （特定の側面を意図的に強調し、それ以 外の側面を意図的に削ぎ落として）抽 象・簡略化した表現 • 特定の課題を解決することを目的とする ※『実践アプリケーション設計①データモデルとドメインモデ ル』の記載内容を再掲
41. (C) Recruit Co.,Ltd. All rights reserved. 41 ドメインモデルとは 該当ドメインにおいて目的を持って抽象化 されたモデル（ドメインの問題を解決する ためのモデル）
42. (C) Recruit Co.,Ltd. All rights reserved. 42 ドメインモデルの種類 • エンティティ • 値オブジェクト • 集約 • ドメインイベント • ドメインサービス
43. (C) Recruit Co.,Ltd. All rights reserved. 43 4-3-1-1. エンティティ
44. (C) Recruit Co.,Ltd. All rights reserved. 44 エンティティ ドメイン駆動設計において、ビジネスドメインの中 心的な存在で一意なものを表現する概念。一意な識 別子をもつ。 例えば「社員」というエンティティの場合、社員番 号で社員を一意に識別することで、同じ人物である ことを把握し、住所や所属といった属性を変更でき る。
45. (C) Recruit Co.,Ltd. All rights reserved. 45 エンティティの識別子について エンティティは各フィールドの変更を許容するが、 識別子は不変であることが重要。 エンティティは識別子を下記で述べる値オブジェク トとして保持することが多い
46. (C) Recruit Co.,Ltd. All rights reserved. 46 4-3-1-2. 値オブジェクト
47. (C) Recruit Co.,Ltd. All rights reserved. 47 値オブジェクト 値オブジェクトは一意に識別する必要を持たないオ ブジェクトを指す。 また、値オブジェクトはエンティティとは異なり、 内部で保持する値は変更不可（Immutable）であ るのが原則。
48. (C) Recruit Co.,Ltd. All rights reserved. 48 値オブジェクトの例 例えば、「社員」エンティティは「社員ID」を識別 子として一意に識別する 一方「社員ID」そのものは単なる値のため、一意な 識別子を必要としないため、値オブジェクトに分類 される。
49. (C) Recruit Co.,Ltd. All rights reserved. 49 他の設計手法の値オブジェクトとの関係 ドメイン駆動設計における値オブジェクトはドメイ ンモデルであり、それ以外の設計手法の単なる値オ ブジェクトとは概念上はやや異なるが、トランザク ションスクリプトで紹介した値オブジェクトとは実 装上はほぼ同じと見て差し支えない
50. (C) Recruit Co.,Ltd. All rights reserved. 50 補足：値オブジェクトとエンティティの 親子関係について 通常エンティティが値オブジェクトを保持すること は多いが、 逆に値オブジェクトがエンティティを保 持することはない
51. (C) Recruit Co.,Ltd. All rights reserved. 51 4-3-1-3. 集約
52. (C) Recruit Co.,Ltd. All rights reserved. 52 集約 階層構造をもつエンティティ（配下にエンティティ及び値オブ ジェクトを持つエンティティ）で一意な識別子を持つ。 通常、ルートエンティティ（Aggregate Root）と呼ばれる 引用元：https://www.amazon.co.jp/-/en/実践ドメイン駆動設計-ヴォーン・ヴァーノン/dp/479813161X/ref=tmm_pap_swatch_0
53. (C) Recruit Co.,Ltd. All rights reserved. 53 集約 集約は、複数の関連するエンティティ（Entity）や 値オブジェクト（Value Object）をグループ化し、 一つのまとまった単位として扱う概念で、通常、 ルートエンティティ（Aggregate Root）と呼ばれ る特定のエンティティをルートとして、配下に他の エンティティや値オブジェクトを保持する形をと る。 集約はドメインモデルの一貫性を保つための境界を 定義し、関連するエンティティや値オブジェクトの 内部の状態をカプセル化する。
54. (C) Recruit Co.,Ltd. All rights reserved. 54 補足：集約とトランザクション境界 トランザクション境界はしっかりと守ること 以下は金融機関の口座の例
55. (C) Recruit Co.,Ltd. All rights reserved. 55 4-3-1-4. ドメインイベント
56. (C) Recruit Co.,Ltd. All rights reserved. 56 ドメインイベント ドメインモデルの一部で、ドメインで起こった出来 事をモデリングする。異なるコンテキスト境界（※ 後述）間の伝送を担う ドメインイベントを使用することで絵、複雑になり がちな出来事を管理し、システム間の連携を柔軟に することができる。
57. (C) Recruit Co.,Ltd. All rights reserved. 57 イベントソーシングの概要 集約がイベントを発行し、それを保存して、モデル の状態変更の追跡に利用する。リポジトリがイベン トストアからイベントを読み込み、それを適用して 集約の状態を復元する
58. (C) Recruit Co.,Ltd. All rights reserved. 58 補足：ドメインイベントの発行場所 ドメインイベントの発行は基本は集約ルート（エン ティティ）内で行う ソースコード例（IDDDのソースコードより） ドメインロジック内で イベント発行
59. (C) Recruit Co.,Ltd. All rights reserved. 59 4-3-1-5. ドメインサービス （Domain Service）
60. (C) Recruit Co.,Ltd. All rights reserved. 60 ドメインサービスとは ドメイン駆動設計では、例えばメールの重複チェッ クのように「エンティティ」、「値オブジェク ト」、「集約」といった「ドメインオブジェクト」 だけではなく、それらの外に記述した方が良いロ ジックも存在する。 そのようなロジックを記述する際に使用するサービ ス。
61. (C) Recruit Co.,Ltd. All rights reserved. 61 ドメインサービスの特徴 • 状態を持たない • トランザクションの責務も担わない • ユビキタス言語で表現される ※ドメインに関係のないものまで書けてしまうので トランザクションスクリプトにならないように注意
62. (C) Recruit Co.,Ltd. All rights reserved. 62 ドメインサービスと アプリケーションサービス 用途や適用されるレイヤーも異なる プレゼンテーション層 アプリケーション層 （ユースケース層） ドメイン層 インフラストラクチャ層 アプリケーションサービス ドメインサービス
63. (C) Recruit Co.,Ltd. All rights reserved. 63 ドメインサービスと ユーティリティクラスの違い ドメインサービスは以下の点でユーティリティクラ ス（ヘルパーもほぼ同様）とは異なるので注意 ユーティリティクラス • 一般的にアプリケーション全体で再利用可能な非 常に汎用的なヘルパーメソッドを提供する ドメインサービス • 特定のドメインに固有のロジックや振る舞いを扱 い、しばしばドメインのエンティティやオブジェ クトと密接に関連する
64. (C) Recruit Co.,Ltd. All rights reserved. 64 補足：ドメインオブジェクトとは
65. (C) Recruit Co.,Ltd. All rights reserved. 65 「ドメインオブジェクト」が指すもの ドメインモデルを実装したものを指す ドメイン知識 ドメインモデル ドメイン オブジェクト
66. (C) Recruit Co.,Ltd. All rights reserved. 66 4-3-1-6. エンティティや値オブジェクト の決まり方
67. (C) Recruit Co.,Ltd. All rights reserved. 67 エンティティと値オブジェクトの違い 最も重要なのが、一意な識別子があるかどうか 引用元：https://khorikov.org/images/2021/2021-09-06-entity-vs-value-object.png
68. (C) Recruit Co.,Ltd. All rights reserved. 68 「住所」はエンティティ or 値オブジェクト? エヴァンスの『ドメイン駆動設計』で「コラム-住 所は値オブジェクト? その質問をしているのは誰 か?」というコラムがあるが、 結論としてはアプリケーションやサービスの種類に よって変わってくる。以降の頁の各ケースではドメ インモデルとしての住所の扱いが変わる
69. (C) Recruit Co.,Ltd. All rights reserved. 69 ECサイトにおける「住所」 ECサービスにおける配送先としてのユーザの住所は、 住所そのものが識別子を持って、一意である必要は ない（家族が同じ住所を登録しても問題ないため、 値オブジェクトになる） ※但し一人のユーザが複数の住所を登録できる場合 は、識別する必要があるためエンティティになる
70. (C) Recruit Co.,Ltd. All rights reserved. 70 郵便サービスにおける「住所」 一方郵便サービスでは、「住所」自体がドメインの 中心的な存在で個々の住所が、一意で識別される必 要がある。また郵便番号との紐付けや、地域の再編 で市区町村名が変更になる可能性があるため、エン ティティとして扱う必要がある。
71. (C) Recruit Co.,Ltd. All rights reserved. 71 電力サービスにおける「住所」① エンティティの場合 電力サービスでは、「住所」は電線と電力サービス の目的地に相当し、一意に識別される必要がある （一緒に住む家族や同居人同士が別々に電気の利用 を申請した場合、重複申請にならないように提供側 の電力会社側が検知できる必要がある）ため、通常 住所はエンティティである。
72. (C) Recruit Co.,Ltd. All rights reserved. 72 電力サービスにおける「住所」➁ 値オブジェクトの場合 但し、独立した住所エンティティを作るのではな く、契約住居等のエンティティに属性として住所を 持たせる場合は、住居は値オブジェクトとなる。
73. (C) Recruit Co.,Ltd. All rights reserved. 73 4-3-1-7. ドメインモデルについての注意 点（ドメインモデル貧血症）
74. (C) Recruit Co.,Ltd. All rights reserved. 74 ドメインモデル貧血症について データモデリングに慣れ親しんだエンジニアが、ド メイン駆動設計を始めてみると、データの格納方法 ばかりに気になってしまうことがよくある。 このようなERモデリング（テーブル構成とリレー ション関係）を先に検討されたエンティティは、DB 項目のプロパティしか存在しない（getter / setterのみ）機能不足なモデルになりがちで、この ようなモデルの多くが、モデルが単なるデータの入 れ物（DTO）になっており、『ドメインモデル貧血 症』になっている可能性が考えられる。
75. (C) Recruit Co.,Ltd. All rights reserved. 75 ドメインモデル貧血症の回避方法 サービス（Application Service, Domain Service）の処理を見直したり、モデルに責務を与 える（モデルで出来ることはモデルにやらせる）こ とで、貧血症を回避できる
76. (C) Recruit Co.,Ltd. All rights reserved. 76 4-3-1-8. ドメインモデル同士の相互参照 について
77. (C) Recruit Co.,Ltd. All rights reserved. 77 集約内の相互参照について 集約内のエンティティが互いに参照し合うことで循 環参照が発生する場合や、過剰な結合が生じる可能 性がある。どうしても相互参照をが必要な場合は、 ドメインの要件に応じた関連性を考慮しながら適切 な設計とモデリングを行い、検討することが重要
78. (C) Recruit Co.,Ltd. All rights reserved. 78 フレームワークの観点 フレームワークやライブラリによっては相互参照は ビルドエラーになるものもある 例えばJPAのように親クラスとその配下のクラスが 互いにプロパティで持ち合うことを禁止するフレー ムワークもあり、エラーを避けるために別のモデル を作る必要が出てくる そのため、相互参照は基本は避けるべき
79. (C) Recruit Co.,Ltd. All rights reserved. 79 4-3-2. ファクトリ
80. (C) Recruit Co.,Ltd. All rights reserved. 80 ファクトリ ドメイン駆動設計におけるファクトリは複雑な集約 の生成を担うモジュール。 （※GRASP原則の「生成者」にも該当） ドメイン駆動設計において、集約は複雑な構造にな りがちなため、その生成に特化したモジュールとし て定義する。
81. (C) Recruit Co.,Ltd. All rights reserved. 81 ファクトリの効用について 複雑な集約の生成処理をカプセル化する（ファクト リ化して一か所にまとめておく）ことで、可読性が 向上し、保守性や拡張性も向上する。
82. (C) Recruit Co.,Ltd. All rights reserved. 82 4-4. インフラストラクチャ層
83. (C) Recruit Co.,Ltd. All rights reserved. 83 インフラストラクチャ層の役割 アプリケーションを支える技術的な機能（ドメイン オブジェクトの永続化や検索）を提供する インフラストラクチャ層の主な構成要素 リポジトリの実装クラス
84. (C) Recruit Co.,Ltd. All rights reserved. 84 4-4-1. リポジトリ
85. (C) Recruit Co.,Ltd. All rights reserved. 85 リポジトリ（Repository） リポジトリは、ドメインモデルとデータベース(また は永続化層)の間の仲介役で、ドメインモデルに対す るデータアクセスの抽象化を提供し、ドメインモデ ルの永続化や取得、更新などの操作を行う。 通常、集約とリポジトリは1対1になる ※永続化（データベースに保存）と業務ロジックと は本来異なる関心事であるため、アプリケーション サービスやドメインモデルから永続化を分離させる
86. (C) Recruit Co.,Ltd. All rights reserved. 86 DDDと相性の良いデータアクセスパターン 以下のうち、④Data Mapperがドメイン駆動設計 で用いられやすい • ① Table Data Gateway • ② Row Data Gateway • ③ Active Record • ④ Data Mapper
87. (C) Recruit Co.,Ltd. All rights reserved. 87 サンプル実装で用いたパターン 今回のサンプルもData Mapperにあたる Hibernate（JPA）+ Repositoryパターンで実装 Data Mapperパターン
88. (C) Recruit Co.,Ltd. All rights reserved. 88 補足：リポジトリとDAOパターンの違い DAO(Data Access Object)は似ているものの、デー タアクセスパターンのTable Data Gatewayパ ターンに該当する
89. (C) Recruit Co.,Ltd. All rights reserved. 89 5. ドメイン駆動設計の アーキテクチャ
90. (C) Recruit Co.,Ltd. All rights reserved. 90 一般的なWebアプリのアーキテクチャ 三層アーキテクチャは低凝集・密結合になりやすい 三層アーキテクチャ プレゼンテーション層 アプリケーション層 （ビジネスロジック層） データアクセス層 クライアントとの入出力 ユースケースの実現 ドメイン知識の表現 データベースとの入出力 依存関係は 「上の層から下の層」 のみ許可する 引用元：https://booth.pm/ja/items/1835632
91. (C) Recruit Co.,Ltd. All rights reserved. 91 ドメイン駆動設計のアーキテクチャ • レイヤード・アーキテクチャ • ヘキサゴナル・アーキテクチャ • オニオン・アーキテクチャ • クリーン・アーキテクチャ
92. (C) Recruit Co.,Ltd. All rights reserved. 92 レイヤードアーキテクチャ 以下のようなレイヤードアーキテクチャが最初のステップ レイヤードアーキテクチャ プレゼンテーション層 アプリケーション層 （ユースケース層） ドメイン層 インフラストラクチャ層 クライアントとの入出力 ユースケースの実現 ドメイン知識の表現 データベースとの入出力 依存関係は 「上の層から下の層」 のみ許可する 引用元：https://booth.pm/ja/items/1835632 ユースケースを実 現する層とドメイ ン知識を表現する 層を分ける
93. (C) Recruit Co.,Ltd. All rights reserved. 93 レイヤードアーキテクチャの問題点 ドメイン層がインフラストラクチャ層に依 存してしまうのがレイヤードアーキテク チャの問題
94. (C) Recruit Co.,Ltd. All rights reserved. 94 DIP（依存性逆転の原則）を用いた アーキテクチャの改善 インフラストラクチャ層にドメイン層が依存する形を是 正（ヘキサゴナルやオニオンアーキテクチャに発展） レイヤードアーキテクチャ プレゼンテーション層 アプリケーション層 （ユースケース層） ドメイン層 インフラストラクチャ層 レイヤーアーキテクチャ （DIP使用時） インフラストラクチャ層 プレゼンテーション層 アプリケーション層 （ユースケース層） ドメイン層
95. (C) Recruit Co.,Ltd. All rights reserved. 95 補足：DIP（依存性逆転の原則）とは DIPとは、高レベルモジュールと低レベルモジュー ルを抽象に依存させることで、モジュール間の結合 度を下げる原則 DIPの例 引用元： https://blog.openreplay.com/ja/%E4%BE%9D%E5%AD%98%E6%80%A7%E9%80%86%E8%BB%A2%E3%81%AE%E5%8E%9F%E5%89%87-%E8%AA%AC%E6%98%8E/ 抽象
96. (C) Recruit Co.,Ltd. All rights reserved. 96 オニオンアーキテクチャ レイヤードアーキテクチャから、依存関係逆転原則を 用いてドメイン層とインフラ 層の依存関係を逆転させ たのがオニオンアーキテクチャ 引用元：https://booth.pm/ja/items/1835632
97. (C) Recruit Co.,Ltd. All rights reserved. 97 オニオンアーキテクチャ（丸型表記） 前頁の図を丸型に表記に変更 引用元：https://booth.pm/ja/items/1835632
98. (C) Recruit Co.,Ltd. All rights reserved. 98 ヘキサゴナルアーキテクチャ 同様にレイヤードアーキテクチャからDIPで発展 引用元： https://www.google.com/url?sa=i&url=https%3A%2F%2Fxtech.nikkei.com%2Fatcl%2Fnxt%2Fmag%2Fnc%2F 18%2F020600014%2F100800073%2F&psig=AOvVaw3ijDPcMAmxsL8WduJY1aY3&ust=1718168227601000&s ource=images&cd=vfe&opi=89978449&ved=0CBAQjRxqGAoTCKiW-8jh0oYDFQAAAAAdAAAAABC5Ag 引用元：https://booth.pm/ja/items/1835632
99. (C) Recruit Co.,Ltd. All rights reserved. 99 クリーンアーキテクチャ 同様にDIPを用いたアーキテクチャ 引用元： https://www.google.com/url?sa=i&url=https%3A%2F%2Fblog.tai2.net%2Fthe_clean_architecture.html&psig=AOvVaw2iym Si4ysmgS73ufQSKexf&ust=1718631929414000&source=images&cd=vfe&opi=89978449&ved=0CBEQjRxqFwoTCODh6v- g4IYDFQAAAAAdAAAAABAo
100. (C) Recruit Co.,Ltd. All rights reserved. 100 各アーキテクチャの違い 三者ともに細かい差異はあるものの、ベースとな る思想（DIP）は共通 引用元2： https://www.google.com/url?sa=i&url=https%3A%2F%2Fblog.tai2.net%2Fthe_clean_architecture.html&psig=AOvVaw2iymSi4ysmgS73ufQSKexf&ust=171863192 9414000&source=images&cd=vfe&opi=89978449&ved=0CBEQjRxqFwoTCODh6v-g4IYDFQAAAAAdAAAAABAo ヘキサゴナルアーキテクチャ オニオンアーキテクチャ クリーンアーキテクチャ 引用元1：https://booth.pm/ja/items/1835632
101. (C) Recruit Co.,Ltd. All rights reserved. 101 6. 事業価値をもたらす ソフトウェア開発に必要なこと
102. (C) Recruit Co.,Ltd. All rights reserved. 102 ソフトウェアと事業価値 事業価値をもたらすソフトウェアを開発すること は、技術面だけでなく、ビジネス面も絡んでくるた め容易ではない。 開発チームがさまざまな知識やスキルセットを持つ 多くの人たちと力を併せて、求められる事業価値を 見出し、優先順位をつけることが重要。
103. (C) Recruit Co.,Ltd. All rights reserved. 103 ドメインエキスパート ドメインエキスパートとは、担当業務やシステムの 対象領域について最も理解した人を指す。 CEOや役員、営業、エンジニア等、様々なケース （職種や役職を限定しない）があり、一人ではなく 複数人いる場合もある。 なお、近年では専門職として採用するケースも増え ている
104. (C) Recruit Co.,Ltd. All rights reserved. 104 事業価値をもたらすために必要なこと ドメインエキスパートとエンジニアとの緊密な連携 が重要 ドメインエキスパート • 事業価値をいかにもたらすかに注力する エンジニア • 技術に注目し、業務的な問題を技術的に解決しよ うとする
105. (C) Recruit Co.,Ltd. All rights reserved. 105 開発現場における理解の齟齬 しかしながら、理解の不一致や認識不足等がしばし ば生じ得る エンジニア ドメインエキスパート 業務知識不足や 思い込み 経験や知識の差から生じる 理解の不一致 技術知識不足や 思い込み
106. (C) Recruit Co.,Ltd. All rights reserved. 106 補足：言葉の意味について 言葉の意味は絶対的なものではない • 記憶の集積から生成されるイメージ • 文脈に依存（様々な前提や条件） • 捉え方（個人の主観） ※『実践アプリケーション設計②トランザクションスクリプト への対応』に記載の内容を再掲
107. (C) Recruit Co.,Ltd. All rights reserved. 107 ユビキタス言語 「ユビキタス言語」とはドメインエキスパートやエ ンジニアを含めたチーム全体で作り上げる共有言語 のこと。 良い設計はまずは用語の意味と理解を一致させるこ とが大事
108. (C) Recruit Co.,Ltd. All rights reserved. 108 ユビキタス言語の重要性 ドメインエキスパートと開発者の対話の中にドメイ ン駆動設計における重要な概念のヒントになるニュ アンスを含んだ言葉が現れることがあるが、それを 見逃さないために、翻訳のコストは極力減らさなけ ればならない。 そうしないと、開発者たちのドメインに対する理解 が中途半端になったり、誤解も加わり、最終的には 本来のドメインの概念と程遠いオブジェクトが具現 化されてしまうことになってしまう。
109. (C) Recruit Co.,Ltd. All rights reserved. 109 ユビキタス言語が浸透していないと ユビキタス言語が十分に浸透していない、あるいは まったく使われないプロジェクトは常に翻訳（メン タルマッピング）をしている状況になる。 そのような場合、ドメインエキスパートは技術的な 専門用語やシステムのことを理解せず、独自の専門 用語で会話を行い、開発者たちはその言葉を自分た ちの言葉へ翻訳することに躍起になりがち。
110. (C) Recruit Co.,Ltd. All rights reserved. 110 7. 基礎知識の確認テスト
111. (C) Recruit Co.,Ltd. All rights reserved. 111 ここまでの知識の確認 別資料『ドメイン駆動設計基礎確認テスト』で実施
112. (C) Recruit Co.,Ltd. All rights reserved. 112 8. ドメインモデリング
113. (C) Recruit Co.,Ltd. All rights reserved. 113 ドメインモデルの探し方 システムの関心事(ヒト・モノ・コト)のうち、コト に注目すると整理しやすい コト 注文 決済 配送 コト ヒト モノ 業務遂行の当事者 個人、企業（法人）、担当者等 ヒトが業務を遂行する際の関心の対象 商品、サービス、店舗、場所、権利、義務、など 業務活動で起こる様々な事象 予約、注文、支払、出荷、キャンセル、など
114. (C) Recruit Co.,Ltd. All rights reserved. 114 コトに注目する理由 特にコトはヒトとモノとの関係として出現する（誰 の何についての行動か）ので、ヒト・モノ・コトの うち、コトに注目すると整理しやすい
115. (C) Recruit Co.,Ltd. All rights reserved. 115 データモデリングと何が違うのか？ データベースのデータモデリングは名詞（5W1H） に着目（『実践データベース設計』）していたが、 ドメインモデリングは何が違うのか データを中心に見るのではなく、業務を中心に整理 する
116. (C) Recruit Co.,Ltd. All rights reserved. 116 補足：ドメインの境界について 業務領域の特定は、さまざまな事業活動がどのよう な事業価値を提供しているかを識別し、ソフトウェ アの実装方法を適切に選択することにつながる 但し、業務領域の境界を特定することは、簡単では ありません。最初から完璧な境界を見つけようと頑 張らず、「役に立つ」境界を探すことに全力を尽く すべき
117. (C) Recruit Co.,Ltd. All rights reserved. 117 9. R書店の設計のユースケースと ビジネスフロー
118. (C) Recruit Co.,Ltd. All rights reserved. 118 9-1. R書店の設計（実践モデリング）
119. (C) Recruit Co.,Ltd. All rights reserved. 119 「R書店」のビジネスフロー 今回想定するビジネスフロー
120. (C) Recruit Co.,Ltd. All rights reserved. 120 決済の仕組み 今回はクレジットカードのみで、ゲートウェイの使 用を想定 引用元：https://www.gmo-pg.com/blog/articles/images/article-096_thumb07.jpg
121. (C) Recruit Co.,Ltd. All rights reserved. 121 顧客のサイト来訪から購入までの流れ 今回のシステムでは顧客の行動として以下を想定
122. (C) Recruit Co.,Ltd. All rights reserved. 122 今回のアクターとユースケース 今回のシステムのアクター • 顧客 サイト管理者 • 配送センター管理者 • 配送会社担当者
123. (C) Recruit Co.,Ltd. All rights reserved. 123 ドメインモデリングの流れ 1. ソフトウェア要件の理解 2. モデリングを検討しエンティティを抽出 3. エンティティを識別する属性と振る舞いを検討 4. 「一意な識別子」の設計 5. エンティティの振る舞い（メソッド）を検討 6. エンティティの作成（コンストラクタ/ファクト リ）を検討 7. エンティティのバリデーションを検討
124. (C) Recruit Co.,Ltd. All rights reserved. 124 9-2. ドメインモデリング例
125. (C) Recruit Co.,Ltd. All rights reserved. 125 ソフトウェア要件の例① （初期） ユーザは氏名の他にユーザ名を持つ ユーザには管理者用や一般ユーザ等複数の種別を持つ ユーザのステータスの変化に関する記録（イミュータ ブルモデル）はどうするのか？（要確認） ユーザに管理用のステータスを持たせる ドメインエキスパート エンジニア
126. (C) Recruit Co.,Ltd. All rights reserved. 126 ソフトウェア要件の例① （洗練後） ユーザは氏名の他にユーザ名を持つ ユーザには管理者用や一般ユーザ等複数の種別を持つ ユーザに管理用のステータスを持たせる ユーザのステータスに関する記録用エンティティ（イ ミュータブルモデル）は作成しない エンジニア ドメインエキスパート
127. (C) Recruit Co.,Ltd. All rights reserved. 127 モデリング① （ユーザエンティティの抽出） 要件のシナリオに登場する名称に注目して モデリングを実施
128. (C) Recruit Co.,Ltd. All rights reserved. 128 「住所」は郵便番号 / 都道府県 / 市区町村 / 丁目・番 地・号 / 建物名 / 部屋番号までを保持する 「住所」はアカウントに紐づいて複数登録できるよう にする でも自分以外の別の人に贈りたい場合はどうする？ 住所は送り先の氏名を持たないといけないのでは？ 住所は内包する要素を全てを連結してFullAdressとし て返す必要があるのでは？ ドメインエキスパート エンジニア ソフトウェア要件の例② （洗練後）
129. (C) Recruit Co.,Ltd. All rights reserved. 129 住所関連の要件（洗練後） 「住所」は郵便番号 / 都道府県 / 市区町村 / 丁目・番 地・号 / 建物名 / 部屋番号までを保持する 「住所」はアカウントに紐づいて複数登録できるよう にする 「住所」は自分以外の別の人に贈る用に送り先氏名を 持つ 「住所」は内包する要素を全てを連結して返す エンジニア ドメインエキスパート
130. (C) Recruit Co.,Ltd. All rights reserved. 130 モデリング② （住所エンティティの抽出） 要件のシナリオに登場する名称に注目して モデリングを実施
131. (C) Recruit Co.,Ltd. All rights reserved. 131 レジに行く前に認証済みである前提で、カートは非ロ グインユーザでも商品追加をができる カートには同じ商品を複数追加できる（数量変更可） ログイン状態でも、非ログイン状態でも同様に扱うた めにユーザIDと非ログインの識別子（クッキーの値 等）の両方で扱えるようにする必要があるな ログインしたらカートCookie値に紐づくカートから ユーザIDに紐づくカートへ切り替えが必要そうだ ドメインエキスパート エンジニア ソフトウェア要件の例③ （初期）
132. (C) Recruit Co.,Ltd. All rights reserved. 132 レジに行く前に認証済みである前提で、カートは非ロ グインユーザでも商品追加をができる カートには同じ商品を複数追加できる（数量変更可） ログイン状態でも、非ログイン状態でも同様に扱うた めにユーザIDと非ログインの識別子（クッキーの値 等）の両方で識別する ログインしたらカートCookie値に紐づくカートから ユーザIDに紐づくカートへ切り替える（カート内商品 も切り替え先に移動する） エンジニア ドメインエキスパート ソフトウェア要件の例③ （洗練後）
133. (C) Recruit Co.,Ltd. All rights reserved. 133 モデリング③ （カートとカート内商品エンティティの抽出） 要件のシナリオに登場する名称に注目して モデリングを実施
134. (C) Recruit Co.,Ltd. All rights reserved. 134 「R書店」における各ドメイン R書店ドメインと各サブドメイン
135. (C) Recruit Co.,Ltd. All rights reserved. 135 R書店のサブドメイン一覧 サブドメイン名 ドメイン種別 店舗サブドメイン コアドメイン 注文サブドメイン 支援サブドメイン 決済サブドメイン 支援サブドメイン 配送サブドメイン 支援サブドメイン 認証・アクセスサブドメイン 汎用サブドメイン ユーザ（管理）サブドメイン 支援サブドメイン 商品（管理）サブドメイン 支援サブドメイン（出版社管理も含む） 在庫（管理）サブドメイン 支援サブドメイン 配送会社管理サブドメイン 支援サブドメイン
136. (C) Recruit Co.,Ltd. All rights reserved. 136 複数のサブドメインをまたがる処理 注文確定(チェックアウト)時の処理は複数のサブドメイ ンをまたがる処理になる
137. (C) Recruit Co.,Ltd. All rights reserved. 137 10. ドメイン駆動設計における データベース設計
138. (C) Recruit Co.,Ltd. All rights reserved. 138 データベースはただの詳細 ドメイン駆動設計やクリーンアークテクチャ等にお いて、データベースはあくまで「詳細（その先は知 らない）」であり、アーキテクチャの構成要素とし て現れることはない。 永続化はアプリケーション層やドメイン層から切り 離され、意識させないことが大事 （ドメインモデルがアプリケーションのベース）
139. (C) Recruit Co.,Ltd. All rights reserved. 139 ドメイン駆動設計とデータ中心設計 でのデータモデリングの違い データ中心設計（トランザクションスクリプト） • 業務分析（業務フロー）等からトップダウン及び ボトムアップでDBのエンティティを抽出 ※『実践データベース設計』より ドメイン駆動設計 • 先にドメインモデル整理してからデータモデリン グする。つまり「DB設計先行」ではなく「ドメ インモデル先行」 • ドメインモデルと同様に「コト」を中心に設計
140. (C) Recruit Co.,Ltd. All rights reserved. 140 ドメインモデル＝データモデルではない 特にモノリシックなアプリケーションではドメイン モデルとデータモデルが似ていることも少なくない が、ドメインモデルは必ずしもDBのレコードと1対 1で紐づくものではない（ドメインモデルはデータ ベースと紐づく概念ではなく、むしろデータベース との密な関係性を回避するためにリポジトリに永続 化処理をまとめている） ※なお、ドメインモデルのエンティティとデータモ デルのエンティティは別であるので注意
141. (C) Recruit Co.,Ltd. All rights reserved. 141 リソース系データモデル ドメインモデルからデータモデル（エンティティ） を抽出する 店舗ドメイン ドメインモデル データモデル （DBエンティティ） カートテーブル <<Entity>> 商品 商品テーブル 例：商品、カートのデータモデルとの関係 <<Entity>> カート（集約） カート データモデル 商品 データモデル 永続化用モデル 生成 生成 永続化 永続化
142. (C) Recruit Co.,Ltd. All rights reserved. 142 イベント系データモデル リソース系と同様にドメインモデルからデータモデ ル（エンティティ）を抽出・マッピングする 例：決済、注文のデータモデルとの関係 <<Entity>> 決済 決済サブドメイン ドメインモデル データモデル （DBエンティティ） 決済テーブル <<Entity>> 注文 注文サブドメイン 注文テーブル 決済 データモデル 注文 データモデル 永続化用モデル 生成 生成 永続化 永続化
143. (C) Recruit Co.,Ltd. All rights reserved. 143 11. サンプルの実装について
144. (C) Recruit Co.,Ltd. All rights reserved. 144 今回のアプリケーションの構成と 使用フレームワーク • SpringBootを用いたモノリシック構成（レイヤード アーキテクチャ） • データアクセスはHibernate（JPA）+ Repository パターン
145. (C) Recruit Co.,Ltd. All rights reserved. 145 サンプルコードの注意点 今回はサンプルのため一部モデルを除き、ドメイン モデルに直接ORM（マッピングする）方法をとって いるため、インフラストラクチャ層と密結合の状態 になっている。また、デフォルトコンストラクタを 解放している ※本来は、ORMの際は別オブジェクトでマッピング してから、変換等でドメインモデルを生成するのが 望ましい
146. (C) Recruit Co.,Ltd. All rights reserved. 146 パッケージ構成についての補足 モノリシックなアプリケーションにしたため、 Springアプリの挙動の安定を図るため、本来のパッ ケージ構成からは変則的なパッケージ構成とした 本来の構成 今回の構成
147. (C) Recruit Co.,Ltd. All rights reserved. 147 本来のパッケージ構成 境界づけられたコンテキスト毎に整理 アプリケーション層 ドメイン層 インフラストラクチャ層 プレゼンテーション層 コンテキストA コンテキストB コンテキストC
148. (C) Recruit Co.,Ltd. All rights reserved. 148 今回のパッケージ構成 Springアプリの安定した挙動を優先した構成（レイヤ毎に整理）に している アプリケーション層 ドメイン層 インフラストラクチャ層 プレゼンテーション層 コンテキストA コンテキストB コンテキストC
149. (C) Recruit Co.,Ltd. All rights reserved. 149 コンテキスト毎にドメインモデルを使い分け 商品関連エンティティを画面毎に使い分け 店舗TOP 商品詳細 カート レジ 商品 書籍 商品 カート内商品 商品 商品 商品管理 商品マスタ 画面 モデル 商品管理コンテキスト 店舗コンテキスト
150. (C) Recruit Co.,Ltd. All rights reserved. 150 サービスのアノテーションについて ここではアプリケーションサービスとドメインサー ビスを区別するために以下のように使い分けた アプリケーションサービス @Service ドメインサービス @Component
151. (C) Recruit Co.,Ltd. All rights reserved. 151 分散処理のトランザクション整合性について 特に注文確定（チェックアウト）時にイベントソー シングを活用する場合、実運用ではトランザクショ ンの整合性の考慮が必要 注文確定（チェックアウト）時のフロー ※詳細はFigJam参照
152. (C) Recruit Co.,Ltd. All rights reserved. 152 ドメインイベントの実装 今回のR書店についてはSpringBootを用いて以下の 簡易的にイベントソーシングを実装 1. RBooksPubshisher内でEventStoreをDIし、 publish呼ばれたらEventStoreに格納 2. EventStoreからサブスクライバへブロードキャ スト
153. (C) Recruit Co.,Ltd. All rights reserved. 153 12. ドメイン駆動設計の 実装に関連した補足
154. (C) Recruit Co.,Ltd. All rights reserved. 154 実装に関連した補足 • エンティティの識別子に関する補足 • サービスについての補足 • エンティティの使い分けについて • ドメイン駆動設計におけるDTOの使いどころにつ いて • 「コレクションオブジェクト」について • 列挙型（Enum）の扱いについて
155. (C) Recruit Co.,Ltd. All rights reserved. 155 12-1. エンティティの「識別子」 に関する補足
156. (C) Recruit Co.,Ltd. All rights reserved. 156 親と子で同じ識別子を持つことについて 結論としてドメインモデルとして一意に識別される のであれば問題ない。 例えば商品と商品在庫のエンティティの両方が同じ 商品IDを識別子として用いてもいても、商品、在庫 それぞれのエンティティの中で一意であれば（異な るエンティティが同じ識別子を使用していても）問 題ない。
157. (C) Recruit Co.,Ltd. All rights reserved. 157 親子で同じ識別子を持つ事例（サンプル） 識別子は親エンティティと子エンティティで被って いても良い。以下は『IDDD本』のサンプルの例： 親と子でのbacklogItemIdを重複保持している 親（BackLogItem） 子（Task）
158. (C) Recruit Co.,Ltd. All rights reserved. 158 12-2. サービス関連の補足 （Scenario）
159. (C) Recruit Co.,Ltd. All rights reserved. 159 補足：シナリオとは 複数のサービスを束ねる処理 ドメイン駆動設計の正式な要素ではないものの、 サービスが多すぎる場合や、Controllerがスッキリ させる目的でシナリオ(Scenario)という概念を用い ることもある
160. (C) Recruit Co.,Ltd. All rights reserved. 160 12-3. 境界づけられたコンテキストに 応じたエンティティの使い分け
161. (C) Recruit Co.,Ltd. All rights reserved. 161 単一エンティティの課題 使用するコンテキストによっては不要なフィールド を持つことになる 例えば親クラスとその配下の子クラスが互いにプロ パティで持ち合うことを禁止するフレームワークも あり、それを使用する場合、エラーを避けるために 別のモデルを作る必要が出てくる
162. (C) Recruit Co.,Ltd. All rights reserved. 162 同一概念の複数エンティティ コンテキストによって複数使い分けることも考えてみる。 例えば、「商品」のモデルを店頭表示用（Product）と管 理用（ProductMaster）に分ける等。 但し、その場合、可読性や保守性を損なわないように注意 店舗用商品 モデル （Product） 管理用商品 モデル （ProductMaster）
163. (C) Recruit Co.,Ltd. All rights reserved. 163 12-4. ドメイン駆動設計における DTOの使用について
164. (C) Recruit Co.,Ltd. All rights reserved. 164 DTO（Data Transfer Object）とは システム内部またはシステム間でデータをやり取り（転送）す るために使われる、データのみを持つオブジェクト 引用元：https://www.amazon.co.jp/-/en/仙塲-大也-ebook/dp/B0DPW38VVV/ref=tmm_kin_swatch_0?_encoding=UTF8&dib_tag=se&dib=eyJ2IjoiMSJ9.ICYS5d0mLx2TFsj1Tq0iRXpTC60iNtfulSGtwXIphY5QeGZ- _bBqBeX8z0Foxr0_Yz0XDm15cbJHZPd0bGNPL7AHobFMid0OvCQwLF9PkCT6gV-Z6DiH0eXZ53X9XzcF.CJ2gWSEaFVHGVgpdgMv8uPgud8RHUOJoXo_bI7GH8G0&qid=1751988304&sr=1-2-spons
165. (C) Recruit Co.,Ltd. All rights reserved. 165 DTOの利点 • カプセル化 • モデルからDTOにデータを移すことで、モデルの 不要なフィールドや振る舞いを外部から隠蔽する • 通信の効率化 • 必要な情報だけを抽出して送信
166. (C) Recruit Co.,Ltd. All rights reserved. 166 画面描画時における問題点 画面は様々な関心事が複合していて、ドメインモデ ルの粒度や構造と整合しにくい場合や画面の表示だ けに関係する判断や加工のロジックをドメインオブ ジェクトに持ち込みたくないケースもある。 そのような場合にDTOを検討する余地はある（但し 多用は非推奨）。
167. (C) Recruit Co.,Ltd. All rights reserved. 167 CQRSパターンについて 「参照に使用するモデルと更新に使用するモデルを分離する」 というアーキテクチャ（読み取りでDTOを用いる） 引用元：https://www.amazon.co.jp/-/en/アーキテクトの教科書-価値を生むソフトウェアのアーキテクチャ構築-米久保-剛 /dp/4798184772/ref=tmm_pap_swatch_0?_encoding=UTF8&dib_tag=se&dib=eyJ2IjoiMSJ9.tkHA8UQTgO72x_wmaAirGaVsKTekWC5lIzHmSmMyhRpNAwPZEaF6kRhMmGfsYU0- mLaTOLmVaF1BotHna0QoeEOG_XabgrMI8qjEQ8vAaUVaoacS_IfKRbd6SkuX_5SKIGODjRWEkQT0miG7Ies2GgLt9NRFDySlb-RLWtKQhZeFCu1BJZ0HO_FkgxTgWgFBMk4NiAvKT- thGYOEv3R0SvrBt18qTZdYFmm1Y_M0qLlX5dKpWavnoaKNOLhHVeMdgPKbfLOzBpsFeK_sCF9UD3GHZHGVWnXVdX_haCk8EEg.PAzzbuSTxSjmaLMbkl-B-0QAnxIv9rbBIgNmyw7iYXk&qid=1752065182&sr=8-1
168. (C) Recruit Co.,Ltd. All rights reserved. 168 CQRSでDTOを用いるメリット 以下のようなメリットがある • 複数集約にまたがるデータを取得する際のコード がシンプルになる • クエリパフォーマンスが上がる、チューニングし やすくなる • 複数集約の条件で絞り込んでのページングができ るようになる
169. (C) Recruit Co.,Ltd. All rights reserved. 169 CQRSでDTOを用いるデメリット 一方、以下のデメリットがある • ドメインオブジェクトのデータが参照されている 場所が追いにくくなる • アーキテクチャ自体が複雑になり、理解にコスト がかかる
170. (C) Recruit Co.,Ltd. All rights reserved. 170 12-5. 「コレクションオブジェクト」 の是非について
171. (C) Recruit Co.,Ltd. All rights reserved. 171 "コレクションオブジェクト"について "Productsというドメインモデルは存在するか?” 例えば内部でProductエンティティのコレクション (例えばList<Product>等)を保持しているProducts というオブジェクト（コレクションオブジェクト） をドメインオブジェクトとして扱うケースと遭遇す ることがある。これを値オブジェクトと捉えようと する考え方もあるが、問題点がある。
172. (C) Recruit Co.,Ltd. All rights reserved. 172 コレクションオブジェクトの例：Products 識別の必要のないオブジェクトが内部に識別すべきオブ ジェクト（エンティティ）を抱えているのは不自然である
173. (C) Recruit Co.,Ltd. All rights reserved. 173 前出の”Products”の問題点 • 識別子を持っていない(従って集約やエンティ ティではない) • 一意に識別されるエンティティ(商品)を内包して いるが、それ自体は一意に識別されない値オブ ジェクトというのは関係性としておかしい
174. (C) Recruit Co.,Ltd. All rights reserved. 174 12-6. 列挙型（Enum）の 扱いについて
175. (C) Recruit Co.,Ltd. All rights reserved. 175 列挙型はエンティティor 値オブジェクト？ Enumは不変であるため、値オブジェクトとして扱 われることが多いが、エンティティと解釈できる場 合もある • 一意の識別子と値の両方を持つ場合 → エンティティと解釈できる場合がある • 単一の値を持つ場合 → 値オブジェクト 引用元：https://www.bing.com/ck/a?!&&p=99eac0d029b41de6JmltdHM9MTcxOTE4NzIwMCZpZ3VpZD0wNTIzYTk5Ny02N2M0LTYzNDUtMmI1NS1iODIxNjYyZTYyZDcmaW5zaWQ9NTIwNA&ptn=3&ver=2&hsh=3&fclid=0523a997-67c4-6345-2b55- b821662e62d7&psq=Vladimir+Khorikov+enum+value+object&u=a1aHR0cHM6Ly9raG9yaWtvdi5vcmcvcG9zdHMvMjAyMS0wOS0wNi1lbnVtLWVudGl0eS12YWx1ZS1vYmplY3Qv&ntb=1
176. (C) Recruit Co.,Ltd. All rights reserved. 176 値オブジェクトの場合の列挙型 以下のように単一の値を持つ場合は値オブジェクト 引用元：https://www.bing.com/ck/a?!&&p=99eac0d029b41de6JmltdHM9MTcxOTE4NzIwMCZpZ3VpZD0wNTIzYTk5Ny02N2M0LTYzNDUtMmI1NS1iODIxNjYyZTYyZD cmaW5zaWQ9NTIwNA&ptn=3&ver=2&hsh=3&fclid=0523a997-67c4-6345- 2b55-b821662e62d7&psq=Vladimir+Khorikov+enum+value+object&u=a1aHR0cHM6Ly9raG9yaWtvdi5vcmcvcG9zdHMvMjAyMS0wOS0wNi1lbnVtLWVudGl0eS 12YWx1ZS1vYmplY3Qv&ntb=1
177. (C) Recruit Co.,Ltd. All rights reserved. 177 エンティティの場合の列挙型 以下のように一意の識別子と値の両方を持つケースは エンティティと解釈可能 引用元：https://www.bing.com/ck/a?!&&p=99eac0d029b41de6JmltdHM9MTcxOTE4NzIwMCZpZ3VpZD0wNTIzYTk5Ny02N2M0LTYzNDUtMmI1NS1iODIxNjYyZTYyZDcmaW5zaWQ9NTIwNA&ptn=3&ver=2&hsh=3&fclid=0523a997-67c4-6345- 2b55-b821662e62d7&psq=Vladimir+Khorikov+enum+value+object&u=a1aHR0cHM6Ly9raG9yaWtvdi5vcmcvcG9zdHMvMjAyMS0wOS0wNi1lbnVtLWVudGl0eS12YWx1ZS1vYmplY3Qv&ntb=1
178. (C) Recruit Co.,Ltd. All rights reserved. 178 13. 紛らわしい概念の整理
179. (C) Recruit Co.,Ltd. All rights reserved. 179 ドメインモデルと概念データモデル (データベース)との違い ドメインモデル • 業務領域（ドメイン）とドメイン知識をベースと したモデル（ビジネスロジックが中心） 概念データモデル • システムに必要なデータの全体像を体系的に表現 したモデル
180. (C) Recruit Co.,Ltd. All rights reserved. 180 ドメインモデルとアクティブレコードの モデルとの違い アクティブレコードは他のデータモデルと異なり、ビジネ スロジックを保持しているため混同されがち ドメインモデル： ドメイン知識を整理しながら、データと振る舞いを同時に 定義していく アクティブレコード： • DBとのマッピングが前提になる（つまり、データ設計後、 後付けてビジネスロジックを追加していく）。 • データとロジックを別々に定義していく手続き型のアプ ローチであるトランザクションスクリプトといえる
181. (C) Recruit Co.,Ltd. All rights reserved. 181 Springの@Entityについて ドメインモデルのエンティティではなく、データモ デルにおけるエンティティを指すので混乱しないよ うに注意
182. (C) Recruit Co.,Ltd. All rights reserved. 182 注意：J2EEコミュニティにおける “Value Object”とは別概念 「バリューオブジェクト」「VO」という名称はデー タ変換オブジェクトの意味で使われることも多いので 混同しないように注意
183. (C) Recruit Co.,Ltd. All rights reserved. 183 14. トランザクションスクリ プトの実装との比較
184. (C) Recruit Co.,Ltd. All rights reserved. 184 トランザクションスクリプトとの比較 • ビジネスロジックがドメインモデルに集約されて おり、モデルはデータと振る舞いがセットになっ ている • サービスが本来の責務（オーケストレーション） に専念する形でスッキリしている • トランザクション境界が守られている
185. (C) Recruit Co.,Ltd. All rights reserved. 185 トランザクションスクリプトのサービス 本来の責務（仲介・調整）以外の処理も担うため、 ロジックも重複しやすい Service bizlogic1() bizlogic2() Data Model Data Model Data Model bizlogic3()
186. (C) Recruit Co.,Ltd. All rights reserved. 186 ドメイン駆動設計における アプリケーションサービス オーケストレーションに特化することが可能 App Service Domain Model domainlogic1() Domain Model domainlogic2() Domain Model domainlogic3()
187. (C) Recruit Co.,Ltd. All rights reserved. 187 15. リファクタリング課題
188. (C) Recruit Co.,Ltd. All rights reserved. 188 専用リポジトリのDL 以下URLからリポジトリをDLしてください。「まず 何が問題なのか」仮説を立てて、取り組むと効果的 です。 URL: https://ghe.misosiru.io/takeshi- fujimoto/rbooks-ddd-jpa-exercise
189. (C) Recruit Co.,Ltd. All rights reserved. 189 16. ドメインモデルの改善
190. (C) Recruit Co.,Ltd. All rights reserved. 190 ドメイン駆動設計における重要な考え方 「モデルは最初から完成しない。 継続的に改善されるもの」 引用元： https://logmi.jp/main/technology/322831
191. (C) Recruit Co.,Ltd. All rights reserved. 191 最初から完成しないとする理由 最初から完璧な設計はできない • 業務の全容や複雑なルールは初期段階では見えない 外部環境・要件は変化する • ビジネスの変化、顧客ニーズ、法制度などに応じ て、モデルも変化が必要 理解が深まることで改善点が見えてくる • ビキタス言語での対話やフィードバックの中で、モ デルの本質が洗練されていく。
192. (C) Recruit Co.,Ltd. All rights reserved. 192 良いモデルと悪いモデル 良いモデル • ドメインの問題を解決するモデル 悪いモデル • ドメインの問題を解決できないモデル • 現実に即していない • やりたいことができない 引用元： https://logmi.jp/main/technology/322831
193. (C) Recruit Co.,Ltd. All rights reserved. 193 ドメインモデルの継続的な改善 良いモデルを作るために必要なこと • ドメインエキスパートとの継続的な対話とコラボレー ション • 運用した知見をモデルにフィードバックして改善する • ソースコードのリファクタリング
194. (C) Recruit Co.,Ltd. All rights reserved. 194 17. その他開発手法や アーキテクチャについて
195. (C) Recruit Co.,Ltd. All rights reserved. 195 ドメイン駆動設計とアジャイル開発 ドメイン駆動設計では要件とモデリング・実装のプ ロセスの繰り返しが前提（つまりアジャイル開発が 前提）となる
196. (C) Recruit Co.,Ltd. All rights reserved. 196 ドメイン駆動設計とマイクロサービス マイクロサービスアーキテクチャはドメイン駆動設 計と相性が良い 引用元：https://cdn-ak.f.st-hatena.com/images/fotolife/d/dskst9/20190113/20190113175834.png
197. (C) Recruit Co.,Ltd. All rights reserved. 197 18. ドメイン駆動設計と トランザクションスクリプトと の使い分け
198. (C) Recruit Co.,Ltd. All rights reserved. 198 ドメイン駆動設計の課題 • 教育コストが高い • ウォーターフォール開発と相性が良くない • 形だけ取り入れた「軽量DDD」になりがち
199. (C) Recruit Co.,Ltd. All rights reserved. 199 ウォーターフォール開発と ドメイン駆動設計 前述の通り、ドメイン駆動設計では要件とモデリン グ・実装のプロセスの繰り返しが前提なるため。そ のため大規模開発で選択されることの多いウォー ターフォール開発では、フェーズごとに厳格な手順 を踏むため、各フェーズでの要件や設計の変更は困 難であり、ドメイン駆動設計のような柔軟性を持っ たアプローチとは相性があまり良くないと言える。
200. (C) Recruit Co.,Ltd. All rights reserved. 200 ウォーターフォール開発で ドメイン駆動設計を取り入れるために しかしながら、例えば、ウォーターフォール開発の 要件定義フェーズで十分なドメイン知識を収集し、 それを基にしたドメインモデルを作成する（データ と振る舞いをセットで設計する）等、ウォーター フォール開発にドメイン駆動設計の要素を取り入れ ることは不可能ではないといえる。
201. (C) Recruit Co.,Ltd. All rights reserved. 201 トランザクションスクリプトの使いどころ トランザクションスクリプトが向いているのは、業 務ロジックが手続き的なデータ操作だけの単純な問 題領域。 たとえば、データの抽出、変換、書き出し操作等。 ※複雑な業務ロジックには適していない
202. (C) Recruit Co.,Ltd. All rights reserved. 202 19. 推薦書籍
203. (C) Recruit Co.,Ltd. All rights reserved. 203 『エリック・エヴァンスのドメイン駆動設計』 ドメイン駆動開発に留まらない、ソフトウェア設計 全体における深い知見が詰まっている 引用元：https://m.media-amazon.com/images/I/51f7WXHJYCL.jpg
204. (C) Recruit Co.,Ltd. All rights reserved. 204 『実践ドメイン駆動設計』 エヴァンスの『ドメイン駆動設計』を実装 した位置付けの通称”IDDD本” 引用元：https://m.media-amazon.com/images/I/91aTKucFSKL._SL1500_.jpg
205. (C) Recruit Co.,Ltd. All rights reserved. 205 『「実践ドメイン駆動設計」から学ぶ DDDの実装入門』 主に入門者向けの技術書で定評のある著 者が“IDDD本”を日本語で解説した書籍 引用元：https://m.media-amazon.com/images/I/81TK4PfumoL._SL1500_.jpg
206. (C) Recruit Co.,Ltd. All rights reserved. 206 『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と 事業戦略を結びつける実践技法』 ドメイン駆動設計とトランザクションスクリプトを対 比させながら、まとめられている良書 引用元： https://m.media-amazon.com/images/I/61mTx74NsJL._SL1419_.jpg
207. (C) Recruit Co.,Ltd. All rights reserved. 207 『現場で役立つシステム設計の原則』 従来のドメイン駆動設計を咀嚼する形で、ドメインモデルを用 いた設計について、Webシステムの基礎から触れている良書だ が、エリック・エヴァンスのドメイン駆動設計とやや異なる点 があるので注意 引用元：https://m.media-amazon.com/images/I/816kPT38qiL._SL1500_.jpg