Recommended
More Related Content
What's hot
What's hot (20)
Similar to 「実践ドメイン駆動設計」 から理解するDDD (2018年11月)
Similar to 「実践ドメイン駆動設計」 から理解するDDD (2018年11月) (20)
More from A AOKI
Recently uploaded
Recently uploaded (9)
「実践ドメイン駆動設計」 から理解するDDD (2018年11月)
- 1. 「実践ドメイン駆動設計」 から理解するDDD 株式会社ネクストスケープ 青木 淳夫 Modeling Forum 2018 技術公演 トラック
- 2. DDD(ドメイン駆動設計)とは ドメイン駆動設計（DDD: Domain-Driven Design）とは 2003年にEric Evans氏が提唱した「顧客と開発者が業務 を戦略的に理解し、共通の言葉を使いながらシステム を発展させる手法」です。 DDDの登場から15年以上が経ち、DDDは着実に普及し つつあります。 本セッションでは、2013年にVaughn Vernon氏が発表 した書籍「実践ドメイン駆動設計（通称：IDDD）」の 流れに沿って、DDDの基本からモデリング手法までを 幅広く紹介します。
- 3. IDDD(実践ドメイン駆動設計)とは 原書名：略称（日本語翻 訳名） 著者（翻訳・監修） 原書発売年 （日本語版発 売年） 内容 日本語版の 総ページ数 Domain-Driven Design - Tackling Complexity in the Heart of Software：DDD本／エ ヴァンス本 『エリック・エヴァンス のドメイン駆動設計』 Eric Evans （和智右桂、牧野裕子 訳 今関剛 監修） 2003年 （2011年） パターン・ラン ゲージ形式によ るDDDの理論 538P Implementing Domain- Driven Design：IDDD 本 『実践ドメイン駆動設 計』 Vaughn Vernon （高木正弘） 2013年 （2015年） DDDの理論と Javaでの実践例 583P
- 4. 当セッションではCodeZine連載「IDDD本から理 解するドメイン駆動設計」 (14回分)を50分で紹 介します https://codezine.jp/article/corner/655 参照
- 5. スピーカー所属企業 株式会社ネクストスケープ 企業理念「お客様のビジョンに共感し、感動を実現します」 https://www.nextscape.net/ 新しいことに挑戦したいエンジニアを募集中です
- 6. 自己紹介 株式会社ネクストスケープ クラウドソリューションアーキテクト 青木 淳夫 主にMicrosoftテクノロジーを活用した開発に従事。 Azureなどのクラウド技術、SitecoreやMarketoといったデジタルマーケ ティングソリューションを用いてビジネス価値を提供。 最近はHoloLensを用いたMR(Mixed Reality)ソリューションの活用も支援。 18年前にエクストリーム・プログラミングに出会って以来、アジャイル によるチーム作りを推進中。Certified Scrum Master/Product Owner/Web解析士 著書3冊に加え、100本以上の技術記事を執筆。 http://profile.hatena.ne.jp/aoki1210/
- 7. IDDD本の構成 IDDD本の目的は 「DDDの理論を実際 に適用する」ことで、 それらを順序だてて 説明しています。 またSaasOvation(サー ズオベイション)とい う疑似プロジェクト を例としたサンプル コードも提供されて います。 主題：実践ドメイン駆動設計 副題(目的)：エリック・エヴァンスが確立した理論を実際の設計に応用する 著者：ヴァーン・ヴァーノン ／ 訳者：高木正弘 実現したい 未来 DDDの戦略 1章 DDDへの誘い 2章 ドメイン 3章 コンテキスト DDDの戦術・ モデリング方法 4章 アーキテクチャ 5章 エンティティ 6章 値オブジェクト 7章 サービス 8章 ﾄﾞﾒｲﾝｲﾍﾞﾝﾄ 9章 モジュール 10章 集約 11章 ファクトリ 12章 リポジトリ 13章 ｺﾝﾃｷｽﾄ統合 14章 ｱﾌﾟﾘｹｰｼｮﾝ
- 8. IDDDサンプルソース IDDD本SaasOvation - Javaのサンプル https://github.com/VaughnVernon/IDDD_Samples IDDD本SaasOvation - C#のサンプル https://github.com/VaughnVernon/IDDD_Samples_NET
- 12. DDDを実践する人のメリット 若手開発者 クリエイティブで面白い開発をしたい。 中堅開発者 適切で正しいソフトウェア開発をしたい。 ベテラン開発者 開発者とビジネス側との距離を縮めたい。事業価値を出したい。 ドメインエキスパート 開発者とスムーズな会話をして良いソフトウェアを作りたい。 マネージャ 開発者が業務知識を得て、ドメインエキスパートと協力して結果を 出してほしい。
- 13. DDDを導入する理由 プログラマーとドメインエキスパートが「共通言語（ユ ビキタス言語）」を用いて視点をあわせることにより、 ひとつのチームとして、あたかも顧客が開発するように ソフトウェアを構築できる。 ドメインエキスパートですら理解が浅い業務領域を深く 検討することによって、業務知識をチームで洗練／共有 し、理想像を検討できる。 「共通言語」をそのままプログラムと実装していく。 「設計がコードであり、コードが設計である」と表現さ れるように、開発時の翻訳コストが不要になる。合わせ て、実装時の課題に設計段階で気づくことができる。
- 16. DDDの導入方法 関係者にDDDがもたらす事業価値を明示する ビジネス的価値 1. コアドメインへの注力 2. 業務の正しい理解 3. 顧客（ドメインエキスパート）による設計 4. より良いユーザー体験 技術的価値 1. モデル間の境界を明確に 2. エンタープライズアーキテークチャの整理 3. アジャイルな継続的なモデリングの実施 4. ユビキタス言語や技術的戦術の活用 重 要 度 高
- 17. DDD推進のポイント DDD向けリソース計画 コアドメインにエースエンジニアを投入 阻害リスク回避 新たな検討時間・作業時間の増加 多忙な顧客（ドメインエキスパート） 保守的な開発者の抵抗 アジャイル技術前提 DDDはアジャイル開発を前提のため、経験あるメンバー を準備
- 21. 「問題領域」と「解決領域」の全体像 広義のドメイン チームが取り 組む事業全体 分析対象となる 問題領 「ドメイン」 問題や課題に取 り組む解決領域 「境界づけられた コンテキスト」
- 22. コアドメインとサブドメイン 「コアドメイン」とは 「コアドメイン」とは事業的に最も重要で戦略的に不可欠な部分です。 「サブドメイン」とは 「コアドメイン」ではない補助的な部分を「サブドメイン」と呼びま す。 サブドメインはコアドメインにとって必要な部分となります。 「支援サブドメイン」と「汎用サブドメイン」とは 「支援サブドメイン」はコアドメインほど重要ではないものの、 業務的に特別なもの 「汎用サブドメイン」は、業務的に特別ではないが、今回のシス テムにおいて必要な箇所
- 24. ドメイン（問題領域）の評価ポイント 構築システムの対象ドメインの整理後には、以下 の項目において評価を行います。 1. 戦略的コアドメインの名前、ビジョン、検討する べき概念が正しいか 2. 必要な支援サブドメインと汎用サブドメインの抜 け漏れがないか 3. 各ドメインの担当者を招集可能か
- 25. 「境界づけられたコンテキスト」とは ドメインの課題を解決する部分を「境界づけられたコンテキス ト」と呼びます。 IDDDでは、1つの「コアドメイン（もしくはサブドメイン）」に、1つの 「境界づけられたコンテキスト」が対応している状態が最適だとされて います。 ユビキタス言語を明確にする「境界づけられたコンテキスト」 DDDでは共通言語として「ユビキタス言語」を作り上げ、そのモデルに 沿って実装します。 ユビキタス言語の意味が変わる境界で「境界づけられたコンテキスト」 を分割して管理します。 DDDの「境界づけられたコンテキスト」は「企業や組織の文化」に近い 意味を持ちます。つまり「境界づけられたコンテキスト」はユビキタス 言語が複数の意味を持たないようにするための明示的な境界と言えます。
- 26. 業種によって「アカウント」という用語の意 味が変わる例。 ユビキタス言語が業種によって変わる例 業種 「アカウント」という用語の意味 会計システム 勘定科目 営業管理システム 顧客 コンピューターシステム ログイン権限
- 27. ユビキタス言語がタイミングによって変 わる例 業務フローのタイミングによって、 ECサイトにおけ る「商品」という用語の意味が変わる例。 順番 「商品」の取り扱い状態 「商品」の呼び名 1 予約中 入荷待ち 2 入荷時 着荷品 3 販売中 在庫品 4 販売後 出庫品 5 トラブル発生時 不良品
- 28. 境界づけられたコンテキストを扱う体制 1つの「境界づけられたコンテキスト」は複数チームではなく、 1つのチームだけで担当します。 ドメインエキスパートは自分の裁量でユビキタス言語を定義し、 シンプルなモデルを構築できます ヴァーン氏はIDDD本でモーツァルトの映画のセリフを引用し 『素晴らしいドメインモデルは、余計な音もなければ、足りな い音もない。調和した交響曲のようなもの』と紹介しています。 DDDのチームメンバーはドメインエキスパートによる言語的な境 界に注目して、高度な技術と豊かな感性にて「境界づけられたコ ンテキスト」と「ドメインモデル」を洗練させていきます。
- 29. 境界づけられたコンテキスト（解決領 域）の評価ポイント 「境界づけられたコンテキスト」が正しいかについては、以 下の項目において評価を行います。 1. 既存ソフトウェア資産の把握（再利用可否と相互接続状況の調査を含む） 2. 新規ソフトウェア資産の検討（開発可能かの調査を含む） 3. 既存ソフトウェアと新規ソフトウェアの統合方法検討 4. 依存する関連プロジェクトのリスク検討 5. ユビキタス言語の抜け漏れの確認 6. 境界づけられたコンテキスト間における「重複または共有しているユビキタ ス言語」の調査とマッピング方法／変換方法の検討 7. コアドメインの概念が境界づけられたコンテキストに適切に含まれているか 確認
- 32. コンテキストマップとは 「コンテキストマッ プ」は複数の「境界 づけられたコンテキ スト」間の関係を俯 瞰する地図です。 システムの全体像や 相互関係を把握する ことができます。 Upstream(上流)が、 影響を与える側、 Downstream(下流)が 影響を受ける側です。
- 36. コンテキストマップの「統合パターン」 ～データとプログラムの連携方法を示す～ （1）共有カーネル （2）巨大な泥団子 （3）公開ホストサービス （OHS：Open Host Service） （4）公表された言語（PL： Published Language） （5）腐敗防止層（ACL：Anti Corruption Layer）
- 37. 3章まとめ 複数の境界づけられたコンテキス トの関係を「コンテキストマッ プ」という地図として書き出すこ とで、他システムを含む、 コミュ ニケーション方法、連携方法を整 理することができます。
- 39. 特定のアーキテクチャに依存しないDDD DDDは特定の技術に依存していないため、自由に アーキテクチャを選択することができます。 アーキテクチャの選定においては、構築するシス テムに求められる「機能要求（ユースケース、 ユーザーストーリー、ドメインモデルのシナリオ 等）」と「品質要求（性能、エラー制御、SLA、 リアルタイム性等）」が大きな判断材料となりま す。 最適なアーキテクチャを選択することは、プロ ジェクト成功に向けて重要なポイントとなります。
- 40. IDDDのサンプル（SaaSOvation）での アーキテクチャの変遷例 項 番 背景 選定アーキテクチャ 詳細 1 デスクトップアプリケーションとして初期開発 レイヤアーキテクチャ C／Sシステムのためクライアント用のアプリ ケーション層とDB層で構築 2 SaaSモデルへの移行に加え、アドオン機能の複 雑化 レイヤアーキテクチャに「依 存性逆転の原則（DIP）」を導 入 DIとユニットテストを導入し品質向上。ドメイ ンに集中し、後にUI層や永続化層を入れ替え 3 スマホへの対応、認証やセキュリティの一元管 理、管理ツール、BIツールなど多数の要望 ヘキサゴナルアーキテクチャ への移行／RESTの導入 ポート＆アダプターの手法により、NoSQL、 メッセージングなどに対応できたことで新機能 への要望に対応 4 レガシーシステムのユーザーデータをクラウド へ移行するサービスの提供 SOAの導入 アプリケーション統合フレームワーク（ESB Mule）を用いてデータをサービスで集約 5 ユーザー別の情報が表示されるダッシュボード の機能拡張 CQRSの導入 コマンド（入力）とクエリ（描画イベント）を 分解して複雑なダッシュボードの表示が可能 6 時間がかかる処理のユーザーストレスやタイム アウトへの対応 イベント駆動アーキテクチャ の導入 「パイプ＆フィルター」パターンを導入 7 30億ドルで買収され、新ユーザー増加とシステ ム統合によりデータが爆発的に増加 分散変更処理への対応 「パイプ＆フィルター」を分散処理対応するた め、「長期プロセス（サーガ）」を導入しイン フラを改善 8 政府より法的な監査の要求 イベントソーシングの導入 ドメインモデルでの全ての変更内容を追跡する ことでコンプライアンス問題に対応 時 間 の 流 れ
- 41. レイヤからDIP(依存性逆転) レイヤアーキテクチャの構成 UI層 アプリケーション層 ドメイン層 インフラストラクチャ層 依存性逆転の原則（DIP）を用いたレイ ヤアーキテクチャ Robert C. Martin氏が提唱したDIPとは 「上位が下位に依存する従来の形をやめ、 抽象が詳細に依存するのではなく、実装 が抽象に依存するべき」という指針。 ドメインが他のレイヤに依存しなくなる ため、ドメイン層を独立させ、シンプル に管理しやすく
- 42. ヘキサゴナルアーキテクチャとは Alistair Cockburn氏が提唱したパターンで、要約すると「アプリケー ション（ドメイン）層を中心に捉え、ユーザー操作／自動テストと いった入力側もデータベース／モックといった出力側も、全てまとめ て差し替え可能な外部インターフェイスとして扱う」という考え方で す。 レイヤアーキテクチャでは、フロントエンドとバックエンドという 「非対称性」な構成でしたが、ヘキサゴナルアーキテクチャでは、ド メインを中心において「処理を駆動するプライマリ」側と「処理が駆 動されるセカンダリ」側と連携します。例えば、何かの処理がある場 合、プライマリ側（左上部分）のアクションによってドメインが呼び 出されます。そして、セカンダリ側（右下部分）によって保存したり イベントを生成したりします。 ヘキサゴナルアーキテクチャは、構成上の仕組みから「ポート＆アダ プタ」とも呼ばれます。システムの目的に応じて「ポート」が設計さ れ、技術的に差しかえが可能な部分が「アダプタ」として用意されま す。「ドメイン」部分は機能やユースケースを基に設計し、「ポート ＆アダプタ」部分は技術的なインターフェース別で設計するイメージ となります。
- 43. CQRS(Command Query Responsibility Segregation)f 従来のプログラミングでは、更新と取得を同じメソッドを記述してい たかもしれませんが、CQRSでは「更新メソッド」と「結果取得メソッ ド」として明確に2つに分離します。
- 44. 結果整合性 「結果整合性」とは「結果として一貫性が保たれることが 保証されていれば問題ない」という考え方です。 標準的なRDBMSアプリケーションでは、ひとつの処理でビ ジネスルールを正しく保つ「トランザクション整合性」が 一般的です。 （例：銀行口座の入出金） これに対しDDDでは、ドメインエキスパートの観点から、 最終的に一貫性が保たれれば多少のタイムラグが合っても 問題がないと判断される場合、「結果整合性」を用いるこ とで複雑性を排除することができます。
- 45. イベント駆動アーキテクチャ イベント駆動アーキテク チャ（EDA:Event Driven Architecture）とは、イ ベントを待機し、起こっ たイベントに応じて処理 を行うプログラムスタイ ルです。 ヘキサゴナルアーキテク チャの場合、複数ドメイ ン間で連携を行うような 分散処理に適しています。
- 46. イベントを記録/再現できるイベントソーシング イベントソーシングの流れは、 発生したすべてのイベントを 「イベントストア」に格納する 点が特徴です。 記録されたイベントを最初から 順番に再生することでオブジェ クトの状態を復元できるため、 監査やバグ調査において力を発 揮します。 またイベントストアを使って、 データパッチを追加することも 可能です。 GitやSubversionといったピンポ イントで過去の状態に復元でき るリビジョン管理ツールの概念 に似ています。
- 49. IDDD本の構成 ここから（5章～ 14章）はDDDの 戦術にあたり、 モデリング方法 とDDDのプログラ ムを構成するオ ブジェクトの要 素について紹介 します。 主題：実践ドメイン駆動設計 副題(目的)：エリック・エヴァンスが確立した理論を実際の設計に応用する 著者：ヴァーン・ヴァーノン ／ 訳者：高木正弘 実現したい 未来 DDDの戦略 1章 DDDへの誘い 2章 ドメイン 3章 コンテキスト DDDの戦術・ モデリング方法 4章 アーキテクチャ 5章 エンティティ 6章 値オブジェクト 7章 サービス 8章 ﾄﾞﾒｲﾝｲﾍﾞﾝﾄ 9章 モジュール 10章 集約 11章 ファクトリ 12章 リポジトリ 13章 ｺﾝﾃｷｽﾄ統合 14章 ｱﾌﾟﾘｹｰｼｮﾝ
- 50. エンティティと値オブジェクト DDDにおける「エンティ ティ」とは一意なものを表現 する概念です。一意であるた め、長期にわたって変化でき るオブジェクトとなります。 例えば「社員」というエン ティティの場合、社員番号で 社員を一意に識別することで、 同じ人物であることを把握し、 住所や所属といった属性を適 切に変更できます。 なお、一意に識別して変更を 管理する必要がないものは 「値オブジェクト」として取 り扱います。
- 51. DDDのモデリングでよくある失敗 DDDで設計を始めてみると、データの格納方法ばかり気になってしま うことがよくあります。 このようなERモデリング（テーブル構成とリレーション関係）を先に 検討されたエンティティは、DB項目のプロパティしか存在しない機能 不足なモデル「ドメインモデル貧血症」になりがちです。 ドメインモデル貧血症とは、オブジェクト指向設計の基本である 「データと処理を一緒に取り扱う」ことを行わない、単なる手続き型 設計のことです。一見、ドメインモデルと同じような構造を持ちつつ も、オブジェクトの「振る舞い」が不足している状態を指します。 そのため、DDDで設計する場合には、DOA（データ中心アプローチ）の ようにデータ中心で検討するのではなく、OOA（オブジェクト指向ア プローチ）のような振る舞いも含めたモデルから検討する方法が適し ています。
- 52. エンティティ発見の流れ DDDでの設計は（DB設計ではなく）オブジェクトモデリングを中心に 進めていきます。 エンティティの発見と検討の流れは次の通りです。 1. ソフトウェア要件の理解 2. モデリングを検討しエンティティを抽出 3. エンティティを識別する属性と振る舞いを検討 4. 「一意な識別子」の設計 一意な識別子の生成方法 一意な識別子の生成タイミング 5. エンティティの振る舞い（メソッド）を検討 6. エンティティの作成方法（コンストラクタ／ファクトリ）を検討 7. エンティティのバリデーションを検討
- 53. ［1］ソフトウェア要件の理解 ドメインエキス パートから要望を 聞き出していきま す。 ここでは業務仕様 を「簡単なソフト ウェア要件」とい う形で書き出して います 「ユースケース」 や「ユーザース トーリー」といっ た成果物を作成す る場合もあります
- 56. ［4］「一意な識別子」の設計 エンティティのモデリングでは、エンティティを識別する「一意な識別子」を検討します。 SaaSOvationでは、テナントは「テナントID」と「テナント名」、 ユーザーは「テナントID」と「ユーザー名」を一意な識別子としています。 4つの一意な識別子の生成パターン No 概要 値の例 メリット デメリット 1 ユーザーが「入力」 USR123 識別子を生成する仕組み が不要 重複せず適切な識別子を利用者に登 録してもらうワークフローやチェッ クの仕組みが必要 2 アプリケーションが「生 成」 "912649a0-0ed2-4071-8af6- 1a350d4adbd0" (UUIDのみ)や "2017-12-31-USER- 1a350d4adbd0" (意味ある値と UUIDの組み合わせ) UUID(GUID)の生成アルゴ リズムを用いて一意な値 を軽量に生成 人間には理解しがたい文字列（その ため、通常は利用者には非表示） 3 永続化メカニズム（DB） が「生成」 10001 Oracleのシーケンス等の 仕組みを用いて連番を簡 単に生成 DB依存が高く性能面の課題がある （早期生成時におけるキャッシュの 仕組みの検討が必要） 4 他の境界づけられたコン テキストから「割り当 て」 USR123やUUID等 識別子生成の仕組みを他 のコンテキストに託せる 他のコンテキストに対して識別子を 取得するための検索／マッチング／ 割り当ての仕組みが必要
- 57. 「一意な識別子」の生成タイミング 生成タイミングについては、「早期生成」と「遅 延生成」の2パターンが存在します。 No 概要 メリット デメリット A 早期生成（オブジェ クト作成時に生成） オブジェクト作成と同時に識別子 を使用可能 DBから識別子を生成する場合は、オブ ジェクト生成時にリポジトリ経由でDBか ら識別子を取得する必要がある B 遅延生成（オブジェ クト保存時に生成） 昔ながらの生成方法で、馴染みや すい オブジェクト生成時にドメインイベント を発行させる場合に、一意な識別子が存 在しない。またオブジェクト生成時に識 別子が未設定（nullや0）のためオブジェ クト間の比較に失敗する
- 59. ［6］エンティティの作成方法を検討 コンストラクタ 「識別子の生成に必要な情報」や「問い合わせを行 うために必要な情報」を引数 ファクトリの検討 エンティティの生成が複雑な場合はコンストラクタ を直接呼び出すのではなく、ファクトリ（11章）を 使用
- 60. ［7］エンティティのバリデーションを検討 エンティティの属性に値をセットする場合、「空ではないか」 「5文字以上か」「30文字以下か」といった妥当性のチェック実 施。 不正な値であればアサーションから違反を示すエラーを発生 契約による設計（Design By Contract：DbC）」 バートランド・メイヤー氏によるプログラムの安全性を高める手法で、事前条 件／事後条件／不変条件という3つの契約種類から構成。 事前条件（precondition）：呼び出し側がメソッド開始時に保証すべき条件 事後条件（postcondition）：呼び出された側がメソッド終了時に保証すべき条件 不変条件（invariant）：データが常に（開始時も終了時も）満たすべき条件 オブジェクト全体のチェックでは、実装クラスに対応した「バリ データ」クラスを作成
- 61. 「一意な識別子」で、エンティティの同 一性を判定 エンティティが同じかという「同一性」を判定する場合、一意な識別 子を使ってオブジェクト同士を比較します（IDDDでは、equalsメソッ ドとhashCodeメソッドをオーバーライドして、一意な識別子の値の組 み合わせが同じであれば、同じエンティティであるとみなしていま す）。 従来のシステム開発ではDB保存時にIDを生成する「遅延生成」が多 かったと思います。しかし遅延生成の場合、一意な識別子にデフォル ト値（nullや0）が設定されているため、異なるオブジェクトが同一と 判定されてしまう問題があります。 この問題に対応するには、遅延生成をやめるか、早期生成でも問題な いようにequalsメソッドとhashCodeメソッドをオーバライドして、識 別子以外で同一性を判断できるようにする必要があります。
- 65. 値オブジェクトとは 「値オブジェクト」は何かを計測したり、定量化したりして説 明する際に使用するオブジェクトです。 数字／文字列／日付をはじめ、姓／名／金額／色といった「ユビキタス 言語」を表現するために活用します。 例えば、電話番号を数値型（Int型）ではなくPhoneNumber型を作るこ とで、ドメインの業務をプログラムでわかりやすく示すことができます。 「エンティティ」とは対照的に「一意に識別して変更を管理す る必要がないモノ」を値オブジェクトとします。 適切に設計していれば、値を想定外に書き換えられてしまうリス クが無いため安心して開発できます。 そのため、使いやすくテストしやすいメリットがあります。保守 性や可読性に優れているため、DDDでは積極的に使用することが 推奨されています。
- 66. 値オブジェクトの特徴 値オブジェクトの特徴として、次の6つを必ず満た すべきと述べられています No 値オブジェクトの特徴 説明 1 計測／定量化／説明 ドメイン内の何かを計測したり定量化したり説明した りする 2 不変性 状態を不変に保つことができる 3 概念的な統一体 関連する属性を不可欠な単位として組み合わせること で、概念的な統一体を形成する 4 交換可能性 計測値や説明が変わったときには、全体を完全に置き 換えられる 5 等価性 値が等しいかどうかを、他と比較できる 6 副作用のない振る舞い 協力関係にあるその他の概念に「副作用のない振る舞 い」を提供する
- 67. （1）計測／定量化／説明 値オブジェクトはドメインの何かを計測、定量化、 説明した結果となります。 例えば年齢や名前の場合、以下の定量化／説明を 行っています。 値オブジェクトの例 計測／定量化／説明する値 年齢 何年生きてきたのかを計測し、定量化した値 名前 何と呼ばれているかを説明した値
- 68. （2）不変性 値オブジェクトはオブジェクトの生成時に値を設定すること はできますが、その後、値を変更することはできません。 従来のプログラムでは値の変更は当然だったと思いますが、 DDDの値オブジェクトでは値が変更できない「不変性」を 持っています。このことにより以下のメリットを受けること ができます。 メリット 説明 シンプルで安全 利用者の想定外の更新操作が原因で、矛盾した状態に陥ることがない。その ため利用者がオブジェクトの内部状態を気にせずに安心して使える。 スレッドセーフ マルチスレッドプログラミングにて、単一オブジェクトに対する複数スレッ ドにおける更新競合を制御する考慮が不要となる。 キャッシュ 値が変化しないことが保障されているため、安心してオブジェクトをキャッ シュできる。
- 77. ドメインサービスの特徴 ドメインサービスの役割は、ドメインモデルが扱う「粒度の 細かい処理」を担うものです。 その処理がエンティティ／値オブジェクト／集約でもない場 合に、ドメインサービスとして実装します。 そのため、ドメインサービスはユビキタス言語として表現さ れます。 ドメインサービスで実装する主な内容としては「さまざまな エンティティ／値オブジェクト／集約を利用して計算するビ ジネスルール」が挙げられます。 また、クライアント側が複雑にならないように、ドメインオ ブジェクトの構成を変換したり、ビジネスロジックをまとめ たりする際にもドメインサービスは使用されます。
- 82. ドメインイベントのモデリング方法 ドメインイベントを見つけるには「ドメインエキ スパートが注目する出来事」にフォーカスします。 具体的にはドメインエキスパートが話す「～する時 に」や「～した場合」といったフレーズに注目しま す。 「システム的な観点」からイベントを導入する ケースもあります。 例えば、特定のシステムで発生した出来事を外部シ ステムに通知する場合や、境界づけられたコンテキ スト内のトランザクションを分離する場合などです。
- 84. イベントを用いた処理の例 1. 同期処理パターン イベント発行と同じトラン ザクションで実施 2. イベント格納処理パターン イベントの記録だけ行いま す。後述する「イベントス トア」等を活用して、イベ ントに応じた処理は別途実 行 3. 分散処理パターン イベントを他システムにリ アルタイムで転送し、2 フェーズコミットなどの 「分散トランザクション」 で制御
- 88. モジュールの設計方法 DDDではソースファイルを物理的に分けるだけではな く、高凝縮で低結合なモジュール化されたモデルを、 ユビキタス言語に従って構築することを推奨していま す。 重要なポイントとして、まず「モジュールの存在を軽 視しない」ことを挙げています。エンティティ／値オ ブジェクト／サービス／イベントと同じ扱いで、モ ジュールについても十分に議論するようにします。 モデリングする際には、正確な意図が伝わるようにモ ジュール名を検討します。必要があれば恐れずにモ ジュール名の変更を行います。ドメインエキスパート とディスカッションしている最新情報がモジュールに 反映されるように努めます。
- 89. モジュールの設計ルール モジュールを設計する指針として、IDDDでは以下のように整理しています。 番号 モジュールの設計指針 1 モジュールをDDDにおいて非常に重要な概念と認識し、モデリングの概念にフィットさせ設計する。例 えば、集約に対して1つのモジュールを用意する。 2 モデリングの概念に従い、モジュール名をユビキタス言語に従う。 3 モジュール名を機械的に決めない。例えば、クラスの型や役割だけでまとめるようなモジュールを作らな い。 4 疎結合に設計する。極力、他のモジュールに依存しないようにする。 5 モジュール同士の結合が必要な場合に、循環依存が起きないようにする。意味的に双方向な依存関係が あっても実装上は単一方向の依存関係が望ましい。 6 モジュール間の循環依存は避けるべきだが、親子関係（上位と下位関係）のモジュールに限り、やむをえ ない場合がある。 7 取りまとめているオブジェクト群に合わせた名前をつけ、そぐわない場合はリファクタリングする。
- 94. 集約が担う境界内の「整合性」 集約はオブジェクト群の「整合性」の境界を保ちながらデータ を更新します。 「整合性」には以下の2つが存在しています。 1. トランザクション整合性 2. 結果整合性 DDDの集約は、即時的な整合性である「トランザクション整合性」 と同義です。 特定のDBのトランザクション命令そのものではありません。あくまで （結果整合性とは対照的に）同期的に整合性を保つ必要性を表してい ます。
- 96. 小さな集約の特徴 大きな集約の問題を回避する 場合、小さい集約を複数作成 することになります。 これまでひとつだった集約を 複数に分解し、各集約それぞ れに集約ルートが存在するこ とになります。 大きな集約を分割し、エン ティティは、別の集約のルー トエンティティとしてモデリ ングしています。 そして、他の集約ルートを直 接参照するのではなく、識別 子（ID）のみを参照していま す。
- 97. 集約の設計ルール 1. 小さな集約を設計する パフォーマンスやスケーラビリティといった非機能要件の観点から、小さな集約になるよう に設計 2. 極力、値オブジェクトから構成する 集約の内部は、ルートエンティティ以外は「値オブジェクト」だけであることが望ましい 3. 真の不変条件（ビジネスルール）を、整合性の中にモデリングする 不変条件とは、どのような操作を行おうとも維持される「ビジネスルール」 4. 他の集約への参照へは、その一意な識別子を使用する 集約では、他の集約ルートへの参照を保持するようにします。 密結合ではなく識別子（ID）を介した参照を使うことで、疎結合に集約を組み合わせることが できます。一般的に複雑になるため双方向の参照も行いません。 5. 境界の外部では結果整合性を用いる 複数の集約にまたがるビジネスルールがある場合には、結果整合性を使うことになります。 この場合、メインとなる集約でイベントを発生させ、受信した側の集約にて処理を継続しま す。
- 98. 大きい集約と小さい集約の比較 大きい集約と小さい集約の比較 集約を小さくすることでトランザクションが衝突しなくな ります。 なお、要件を満たすだけの性能が出せるかは、実際のシナ リオに基づいた検証を行う必要があります。 項目 大きい集約 小さい集約 トランザクションの衝突 多い 少ない 設計難易度 低 中 スケーラビリティ・性能 低 高 エンティティ間の依存 直接参照 ID参照
- 101. DDDのファクトリとは 開発における一般的な「ファクトリ」とは、複雑になり がちなオブジェクト群を簡単に組み立て、呼び出し側に 対して内部構造を隠して生成する仕組みのことを指しま す。 これに対して、DDDのファクトリでは「ユビキタス言語 を用いて集約をシンプルに生成する」という意味合いが 強くなります。 DDDのファクトリとしては、下記のようなシナリオが中 心となります。 1. 特定の集約にて、別のオブジェクト（主に集約）を生成 2. サービスにて、別の「境界づけられたコンテキスト」のオブ ジェクトを、ローカルの「境界づけられたコンテキスト」の型 のオブジェクトに変換して生成
- 102. ファクトリを使う理由 エヴァンス氏は、「車のエンジン」や「銀行口座」 を例にファクトリを利用する理由を紹介しています。 エンジンの場合「複数部品を使ってエンジンを組み立 てたてる処理」と「回転する処理」を分けています。 銀行口座の場合「口座の開設処理」と「口座の取引処 理」を分けています。 このように複雑な生成処理を分離することで、全体 を理解しやすくできることがファクトリのメリット と紹介しています。
- 103. ファクトリの設計 オブジェクトの生成パターンとしては、次の3パターンが想定 できます。 IDDDでのファクトリの種類 メソッドの場 所 メソッド名 特徴 (1)コンストラクタ クラス本体 クラス名 コンストラクタのためシンプル。ユビキタス 言語ではない。複雑な生成（他の集約の生成な ど）に適さない。引数が多い。 (2)集約上のファクトリ 集約 ユビキタス言語 複雑な生成が可能。不変条件を満たしたり、 引数を減らしたりすることができる。 (3)サービス上のファクトリ ドメインサー ビス ユビキタス言語 境界づけられたコンテキスト間の変換が可能。
- 104. 不変条件を満たすファクトリ DDDのファクトリにおいては「一貫した状態のオブジェクトだけを 返す」という制約があります。 利用者は、複雑な生成ロジックを意識することなく、簡単に正しい オブジェクトを取得できます。 その際に、生成される集約の状態が一貫して正しいこと、つまり、不 変条件が正しく守られていることが重要な役割となります。 このように、ファクトリは生成するオブジェクトに対して、アトミッ ク性（原子のように、それ以上細かい単位や要素に分割されないこと。 すべて完了するか1つも実行されないこと）を保ち、中途半端に生成さ れないことを約束します。
- 107. リポジトリとは DDDにおけるリポジトリは、エンティティや値オブ ジェクトから構成される集約の格納と取得を担当しま す。 リポジトリは、クライアントへ集約を提供し、背後の データベースとのやり取りを隠ぺいします。 通常、集約とリポジトリの関係は一対一になります。 例えば「注文」の集約を利用したい場合「注文リポジト リ」を使用します。 クライアント側はリポジトリのおかげで、物理的な構成 （RDBなのか、NoSQLなのか等）を意識せずに、簡単に 集約を操作できます。
- 108. リポジトリで集約を操作する流れ 「A.新しい集約をデータベースに追加する 流れ」の場合 クライアント側からファクトリを呼び出し て集約を生成します。 そして、リポジトリの追加メソッドを呼び 出すことで永続化の対象として登録します。 これによってデータベースに集約の情報が 挿入されます。 「B.データベースから集約の情報を取り出 し、再構成する流れ」の場合 リポジトリはデータベースにクエリを投げ てデータを取り出します。 そしてファクトリを使って集約のモデルを 再構成し、クライアントに集約を戻します。 取り出した集約の変更内容はデータベース へ反映されます。
- 110. 「コレクション指向」と「永続指向」リポジトリ 「コレクション指向のリポジトリ」 集約の登録時に「追加メソッド（Add）」を 用います。 リポジトリは、登録された集約の情報をRDB に書き込みます。 IDDDではO/Rマッパー（Hibernate等）の仕 組みでオブジェクトの変更を検知し、複数の テーブルに反映します。 「永続指向のリポジトリ」 集約の作成／変更時に「保存メソッド （Save）」を呼び出します。 リポジトリでは、保存メソッドが呼ばれたタ イミングで、集約のキーを元に、NoSQLに保 存します。 集約の階層構造を1つのデータ（ドキュメン ト）として保存します。そのため、差分的な 変更ではなく、集約全体を一括で更新します。
- 114. 分散システム構築時の原則 分散システムの構築は一般的な集中システムに比べると簡単ではあり ません。 そのため開発者は次の「分散コンピューティングに関する原則」を理 解する必要があります。 1. ネットワークは信頼できない 2. ある程度の（時にはかなりの）遅延が常に発生する 3. 帯域幅には限りがある 4. ネットワークはセキュアではない 5. ネットワーク構成は変化する 6. 管理者は複数人存在する 7. 転送コストはゼロではない 8. ネットワークは一様ではない
- 115. イベントを連携する「Notification（通 知）」の仕組み DDDで外部の境界づけられた コンテキストに情報を連携す るには「ドメインイベント」 を使用できます。 IDDDでは、このイベントを 「Notification（通知）」と いう仕組みを用いて連携しま す。 RESTfulサービスで公開され る場合もあれば、RabbitMQ のようなメッセージング基盤 を用いて連携される場合もあ ります。
- 119. ドメイン層とUI層間における情報の受け 渡し方法 1. 複数の集約情報を DTOへ詰め替え 2. 複数の集約へ参照 を保持するDPOを 返送 3. ユースケースに最 適化したクエリに よる取得
- 121. UI層での描画に関わるモデル 「ビュー」と「プ レゼンテーション モデル」 1. UIの表示（描画） を行う「ビュー」 2. UIの状態とUI固有 ロジックを持つ 「プレゼンテー ションモデル」
- 122. UI層にドメインモデルを公開するかの判 断 ドメインモデルを公開 ユビキタス言語で使いやすく、バリデーションチェッ クが有効なモデルを利用できるといったメリットがあ ります。 しかし、UIとドメインモデルが密結合となるため相互 に変更の影響を受けやすくなります。 ドメインモデルを非公開 UI層は、DTOとプリミティブ型（Int,String等）のみを 参照することになります。 これによりUIとドメインモデル間を疎結合にできます が、中間的なメッセージモデルへの詰め替えコードが 冗長になってしまいます。 IDDD本では好みや最終目標のトレードオフにて選ぶ ことを推奨しています。 項目 ドメインモデル公開 時 ドメインモデル非公 開時 性能 ○（変わらない） △（DTO詰め替えに よるメモリ使用とガ ベージコレクション コストが発生） 依存関係 △（ドメインモデル への依存性が高く結 合度が高い） ○（ドメインモデル への依存がなく結合 度が低い） 型による妥当性 チェック ○（使える） △（使えない） コード量 ○（増えない） △（DTO部分や詰め 替え部分が増える） 複数クライアント時 の対応 △（ドメインモデル において影響がない ように複数クライア ントを考慮する） ○（複数クライアン ト別にDTOを用意す るためドメインモデ ルに影響がない）
- 124. 最後に