Download as PDF, PPTX
More Related Content
![ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]](https://cdn.slidesharecdn.com/ss_thumbnails/2022-220117111455-thumbnail.jpg?width=640&height=640&fit=bounds)
実践に向けたドメイン駆動設計のエッセンス
- 1. 実践に向けた ドメイン駆動設計のエッセンス 2015年5月27日 増田 亨 有限会社システム設計代表 ギルドワークス株式会社 取締役
- 2.
- 3.
- 4.
- 5.
- 6.
- 7. 要点は全部で２８ページ 「まえがき」 ９ページ １部の導入 ４ページ ２部の導入２ページ ３部の導入 ５ページ ４部の導入 ２ページ 「結論」 ６ページ
- 8.
- 9. 今日の旅行日程 • 「まえがき」 から出発中核の概念 • 第１部の導入 基本用語の説明 – モデル/ドメイン • 「結論」に飛んで、どこを目指しているかを見学 • 「まえがき」に戻って、前提と方向性の確認 – 複雑さという課題 – 設計対開発プロセス – 本書の構成 – 本書が対象とする読者／ドメイン駆動チーム • 第１部の導入から、３つの基本活動を理解する – 知識をかみ砕く／言葉を使う／モデルと実装を結びつける • チームのドメイン駆動設計力を高める体験型の学習 • 総合演習とその実践 モデルの成長のさせ方 ※ 2部、3部、4部は、「本書の構成」と「体験型学習」で触れます
- 10.
- 11.
- 12. ドメイン駆動設計の核心 • ドメインモデリングと設計 • オブジェクトコミュニティでの実践 •設計のイテレーション • 「進化」を続けるドメインモデル • チームで体系的に取り組む
- 13.
- 14. ドメインモデリングと設計 • 不可分 • モデルと設計をいつも関係づける •同じチームが両方やる • 毎日、モデリングと設計をやる アンチパターン ⇒ モデリングと設計の工程を分ける ⇒ 担当者／チームを分ける
- 15.
- 16.
- 17. オブジェクト指向ではない世界 • 手続き型プログラミング • 機能分割・工程分割・役割分割 •技術駆動（計算機駆動） • 自分たちの体に染みついた世界 • オブジェクト指向の道具を使って、 アジャイルを実践しているつもりでも、 手続き型から抜け出せていない 実践の勘所 ⇒ここに気づく ⇒抜け出す努力 ⇒チームで アンチパターン
- 18.
- 19. 「進化」を続ける 豊かなドメインモデル • 成功したプロジェクトに共通する特徴 • ドメイン駆動設計の目指すところ •８年間やってみて –どういうことか、ようやくわかってきた –その威力を実感し始めている –大きな可能性が見えてきた
- 20. チームで体系的に取り組む • この本を貫く基本の価値観 • チーム –「言葉」を使って意図を伝達しあう – 「言葉」を使う力は、チームの全員が持っている – この力を磨いてモデリングと設計に活用する • 体系的 – さまざまな活動の有機的なネットワーク構造 – いったりきたりしながら安定する – 変化を繰り返して成長する
- 21. ドメイン駆動設計の核心 • ドメインモデリングと設計 • オブジェクトコミュニティの実践 •設計のイテレーション • 「進化」するドメインモデル • チームで体系的に取り組む
- 22.
- 23.
- 24.
- 25. ドメイン • ソフトウェアウェアを利用する人た ちの活動と関心事 – ソフトウェアの利用は、活動全体の一部 –関心事の焦点は、ビジネスや業務上の成果 • ドメインではないこと – ソフトウェアを作る活動 – コンピュータの仕組みや挙動 – 画面仕様書/機能一覧/ユーザーストーリー/…
- 26.
- 27. ドメインのモデリング • 利用する人たちの「活動」と「関心 事」を要約する • 「活動」の要約 –アクティビティ図／業務フロー図 •「関心事」の要約 –概念モデル図 （クラス図／パッケージ図）
- 28.
- 29. 活動の文脈のモデリング • 活動の目的や背景の要点を見つける – 「深いモデル」や「コアドメイン」の発見につながる •情報源 – システム企画書／稟議書 – 事業計画／企業文化 – 経済環境／社会情勢 • コンテキスト図 – 登場人物 – 関連システム – 基本目的の箇条書き
- 30. ドメインモデリング • ドメインモデリングは、ソフトウェアの 外部の世界を学び理解する活動 • 視野を広げる –使う人たちの活動や関心事へ –使う人たちの活動の目的や背景へ •視野を広げるほうが、ドメインの 理解が楽になる 実践の勘所 ⇒ ドメインをチームで学ぶスキルアップ
- 31.
- 32.
- 33. 「結論」 • 成功とは？ – ドメイン駆動設計は、なにをもって成功なのか •チームに現れる特徴 – ドメイン駆動設計に真剣に取り組むと何がチーム に何がおきるのか • 学び考える – 優れたソフトウェアを作る中核の活動 • 「深いモデル」 「しなやかな設計」
- 34.
- 35.
- 36.
- 37. 学び考える • 優れたソフトウエアを作る核心 • ドメインモデルを探求し、それをソ フトウエアで表現する活動 •チームで学び考える • 「言葉」を使う力を磨き活用する
- 38.
- 39.
- 40. 「まえがき」 • 複雑さという課題 • 設計とプロセス •本書の構成 • 本書が対象とする読者 • ドメイン駆動チーム
- 41. 「複雑さ」 • ソフトウェアが複雑になるのは、ソフト ウェアを利用する人の行動や関心事が 複雑だから –たとえば if文の複雑さの原因 –たとえばひとつの変更がさまざまな画面 に影響する原因 • ドメイン駆動設計は、ドメインの複雑さと 格闘して、わかりやすいソフトウェア設 計をするための考え方とやり方
- 42.
- 43. 「設計とプロセス」 • 設計とプロセスは不可分 • ドメイン駆動設計の基本はXP 特に以下の２点 –設計のイテレーション –言葉を使った意図の伝達の効果 •ドメイン駆動設計の文脈で XPを学びなおす
- 44. XP • 設計重視 – 毎日、設計に投資する –動いたあとも設計の改善に投資する（リファク タリング） • 費用対効果 – 未経験での設計より、経験や事実に基づく設 計のほうが費用対効果が大きい – up front 設計が投資効果がある時はやる べき – ドキュメントが投資効果がある時は作るべき
- 45. 「本書の構成」 • 第１部 ドメインモデルを機能させる –ドメイン駆動設計の基本的な目標 • 第２部 モデル駆動設計の構成要素 – オブジェクト指向ドメインモデリングの基本 • 第３部 より深い洞察に向かうリファクタリング – 役に立つ実用的なモデルを見つける原則とテク ニック • 第４部 戦略的設計 – 第１部で示した目標をより大きな規模で実現する
- 46. 第１部 ドメインモデルを機能させる • ドメイン駆動設計の基本的な目標 • 第１部（１章、２章、３章）の理解が第２部以降の前提 •ここの理解とスキルアップが実践の勘所 – １章 知識をかみ砕く – ２章 コミュニケーションと言語の使い方 – ３章 モデルと実装を結びつける • 体験しながら学ぶ – 知識をかみくだき蒸留する – 言葉を使った意図の伝達／モデルと設計のテスト – モデルをコードで表現する
- 47. 第２部 モデル駆動設計の構成要素 • オブジェクト指向ドメインモデリング – 初心者には難しい –チームでドメイン駆動設計を実践するには、 初心者向けのスキルアップの工夫が必要 • 体験しながら学ぶ – 誰でもすぐ実践できるオブジェクト指向の基本 – 現場で使えるドメインモデリングの基本
- 48. 第３部 より深い洞察に向かう リファクタリング • 役に立つ実用的なモデルを見つけるには、こ の実践が必須 – 暗黙的な概念を明示する –しなやかに設計し、実験と変更を繰り返す • 内容がわかりにくい • 体験しながら学ぶ – 「ドメイン駆動設計」の視点で「リファクタリング」を やってみる
- 49. 第４部 戦略的設計 • 第１部の内容の理解が大前提 – 「知識のかみ砕き」を大規模に実践する –「言葉を使った意図の伝達」を大規模に実践する – 「モデルと実装の結びつけ」を大規模に実践する • 体験しながら学ぶことはむずかしい領域 – ビッグローブの開発部門の主要メンバーが集まっ てやった「コンテキストマッピング」は、貴重な体験 になっている／ドメイン駆動チームの今後が楽しみ
- 50. 「対象とする読者」 • 「中級」のオブジェクト指向ソフト ウェアの開発者 • オブジェクトモデリングの「若干」 の知識 •この前提は、ハードルが高い –目の前の現実 「手続き型」の「プログラミング」経験者
- 51. 現実から出発する • 手続き型から抜け出せていない • オブジェクト指向設計のスキルと経験の不足 •オブジェクトモデリングの知識と経験の不足 • ドメイン駆動設計を実践するために、チームで この現実を変えていく • オブジェクト指向のモデリングと設計の基本ス キルを、チームで体験しながら学んでいく
- 52. 「ドメイン駆動チーム」 • ドメイン駆動設計は チームで実践する時に 最大の収穫を得る • チームで、ドメインモデリングと設計の 基本を学び、スキルを磨いていく •言葉を使う能力を磨き、モデリングと 設計に活用する
- 53. ドメイン駆動設計 • ドメインがもつ複雑さに挑戦する • イテレーティブな活動 •オブジェクトモデリングの実践 • オブジェクト指向ソフトウェア開発の実践 • チームで「言葉」を使う活動
- 54.
- 55. モデルを中心にした活動 • １章のテーマ –モデルを生みだす活動 • ２章のテーマ –モデルを改善する活動 •３章のテーマ –モデルと設計と結びつける活動
- 56.
- 57.
- 58. 実践の土台づくり • ソフトウェアを使う人たちの 活動と関心事を学ぶスキル • 学んだ知識を要約するスキル •モデルの改善に 「言葉」を使うスキル • モデルと実装を結びつけるスキル
- 59. 体験しながら学ぶ • 現場で、実際の案件で – OJT –もっとも効果的 – ただし障害だらけ • 実際のチームで、現場からちょっと離れて – 現実の案件をテーマに – 納期、費用、過去の習慣の縛りをはずして • 架空のチームで、架空の案件で – 疑似体験
- 60. チームで学ぶ体験型学習講座 お品書き • ドメイン駆動力 – 利用する人たちの活動と関心事を学ぶスキル –ドメインモデリングの「ひきだし」を増やす • モデル駆動力 – 要約するスキル • 長い文章から要点を選び出す • 要点を視覚化しながら整理する • 設計力 – モデルと実装を結びつけるスキル • リファクタリング ドメイン駆動設計版
- 61.
- 62.
- 63.
- 64. ドメインを学ぶコツをつかむ • まずはつかる • 量は質を生む •言語のシャワー • 話すことでわかる • 広げながら掘り下げる • 鳥の眼と虫の目 …
- 65. 学習パターンの使い方を学ぶ • 各自、読んでみる – ホームページ –小冊子（PDF) • 学習パターンを参考にチームで話し合う – ドメインを学ぶために不足していること – ドメインを学ぶための行動計画 • 「ドメインエキスパート」への期待ではなく、自 分たちが起こす行動に焦点をあてる
- 66.
- 67. オブジェクトモデリングの基本部品 • Entity/Value Object/Serviceの３分類は、 抽象的すぎる • もうすこし具体的に、業務やビジネスのドメイ ンのモデリングする時の「部品」を覚えるほうが、 わかりやすい • 「部品」 – 「完成品」ではなく「出発点」 – 「浅い」モデルをさくっと作るための道具 – ここから「豊か」で「深い」モデルを探求していく
- 68. 関心事の基本部品 • ５種類の対象 ヒト・モノ・コト 時・場所 –どう 「識別」 しているか – どう 「説明」 しているか – どう 「関係」 しているか • 具体的に例をあげて話あってみる • 「豊かな」モデル、「深い」モデルへの手掛りを見つ ける練習 – ５種類の任意の２つの組み合わせ（２０パターン）の 「関係」について、具体例をどんどんあげてみる
- 69. よくでてくる関心事 • 「識別」と「説明」 • 「記録」と「通知」 •「勘定」 （履歴と状態） • 「約束」と「期日」 （将来の「コト」の約束） • 「契約」と「計画」 （履行責任） • 「照合」と「消込」 • 「分類」と「方針」 （区分とビジネスルール） • 「横顔」と「選好」と「所見」 （個性と判断）
- 70. よくでてくる関心事の学び方 • みんなが先生役になって発表しあう （教えることによる学び） – パターンを説明する –具体例をあげる • 参考文献 データモデリング系も参考にしている
- 71.
- 72. 長い文章から要点を選び抜くスキル • 題材 – ドメイン駆動設計の要点２８ページ •段落を40字に「要約」してみる（各自） • お互いの「要約」を比べる – 同じところ／違うところ – 「要約」の意図や迷った過程を説明する • よりしっくりくる「要約」を声に出して作ってみる • 書いて読んだ時にしっくりくるか確認する
- 73. 要点を図を使って整理するスキル • 題材 – 実際の案件 –７章の貨物輸送システム • 手法 – リレーションシップ駆動要件定義(RDRA) – 目的や背景を整理⇒価値モデル（コンテキスト図） – 「活動」を要約⇒業務モデル（アクティビティ図） – 「関心事」を要約⇒概念モデル（クラス図） • 狙い – チームで、ドメインモデリングの基礎を習得する
- 74. リレーションシップ駆動要件定義 参考文献 • 神崎善司さん • 要件定義の実践手法 •システムを取り巻く環境（=ド メイン）を理解し、システム と関係づけることを重視し た手法
- 75.
- 76. ドメインモデリング演習 • 一枚のメモ書き （システム企画書のドラフト） •２時間 さくっとドメインモデリング – メモを読む – 目的を要約する ⇒ コンテキスト図を描く – 利用者の活動を要約する ⇒ アクティビティ図を描く – 利用者の関心事を要約する ⇒ 概念クラス図を描く – メモ／コンテキスト図／アクティビティ図／概念クラス図を整合さ せる • ２時間 モデルの改良 – お互いのモデルを説明しあう – 違いを話あう （言葉にする／耳を傾ける／矛盾を見つける） – 話し合った内容の気づきを、自分のモデルに反映する
- 77. 設計力 「リファクタリング」のドメイン駆動設計版 モデルと実装を結びつけるスキル 第３章 モデルと実装を結びつける 第４章 ドメインを隔離する 第９章暗黙的な概念を明示的にする 第10章 しやなかな設計 第16章 大規模な構造
- 78. 設計力をあげる • ドメイン駆動設計に必要な設計力 – 第１０章しやなかな設計 • 意図の明白なインタフェース （手段の隠ぺい） • 概念の輪郭と一致させる • 独立性を高める （組み立て型の柔軟性） • ドメイン駆動設計のいやな臭いと処方箋 • 意図がはっきりしないメソッド／クラス／パッケージ • 利用する人たちの関心事（概念）と一致しないコード • 複雑に絡み合ったクラス／パッケージ
- 79.
- 80. ドメイン駆動設計の文脈で コードのいやな臭い探しと改善体験 • 重複したコード • 長すぎるメソッド •巨大なクラス • 長すぎるパラメータリスト • データの群れ • 基本データ型への執着 • スイッチ文 • コメント • 疑わしき一般化 • メッセージの連鎖（メソッドチェーン） • データクラス • プレゼンテーション層へのビジネスロジックの分散 • データソース層へのビジネスロジックの分散 • ．．． ドメイン駆動設計として何が問題か？
- 81. オブジェクト指向に頭を切り替える • 「手続き型コード」の発見と修正を体験する – 既存のコードを調べる –手続き型からオブジェクト指向に書き換えられそう な箇所を発見する ⇒ 次の「良い部品」参照 – 実際に書きなおしてみる
- 82. 良い部品 • 意味のある単位にコードを分ける – 段落に分ける –メソッドの抽出 – クラスの抽出 – パッケージの導入 • 利用者の関心事を「名前」で説明する – 説明用の変数 – 説明用のメソッド – 説明用のクラス – 説明用のパッケージ
- 83. 良い部品 • Value Object –ドメインに特化したString • PersonName, MailAddress, Telephone, … – ドメインに特化したInteger/Decimal • Money, Quantity, Rate, … – ドメインに特化したLocalDate • DueDate, ExpireDate, DateOfBirth • ファーストクラスコレクション – 一覧、履歴、グループ • Products, Members, PurchaseHistory, … – 利用者の関心事をクラスで明示する ループ処理の隠ぺい データ操作の隠ぺい
- 84. 良い部品 （分岐の表現） • ガード節 –if/else を 早期リターンを使って分解する – 複文を複数の単文に ⇒ 独立した部品 • １箇所だけの分岐構造 – 同じ分岐構造を複数個所に書かない • 多態 – State/Strategy パターンで、分岐ごとのロジックを 別オブジェクトに – Enum（列挙） で、区分の構造を宣言的に – Enum（列挙） で、区分に振る舞いを持たせる
- 85.
- 86.
- 87.
- 88. 実装技術 • Spring Boot –フレームワーク自体が三層＋ドメインモデル指向 • @Controller/@Service/@Repository – サンプルが三層＋ドメインモデルになっている • プレゼンテーション層 – Spring MVC HTTPとドメインモデルの変換技術 – Thymeleaf HTMLを尊重したビュー技術 • データソース層 – myBatis SQLを尊重したオブジェクトマッピング
- 89. 三層＋ドメインモデル 設計の改善 • ドメインモデルに、利用者の関心事を集中する – 豊かなモデル／ 深いモデル への道筋 • いやな臭いとリファクタリング – プレゼンテーション層にまぎれこんだドメインロジック • 新着アイコンをつけてわかりやすく ⇒ ドメインの関心事 • ビューに if(新着) を書かない工夫 – データソース層やSQLにまぎれこんだドメインロジック • 動的にSQL組み立てない工夫 – 多態を使った検索の切り替え • WHERE句やORDER BYの意図をドメインオブジェクトで表現 – SQLに渡すパラメータオブジェクトの設計改善
- 90. 大きなリファクタリング ドメインモデルの構造の改善 • コードを読んでもはっきりしない問題 – パッケージの名前 –パッケージの階層構造（ファイルシステム上） – パッケージの依存関係（パッケージ図） • 改善の必要性を発見する – わかりにくさを感じたら • 声に出してモデリングしてみる • 絵にしてみる （特に依存関係） • 改善の手段 – 名前の変更 – パッケージの分割／統合／追加 – クラスの移動による依存性の単純化 – クラスの分割＋クラスの移動による依存性の単純化 – 業務の時系列とパッケージの依存関係の突き合わせ
- 91.
- 92.
- 93.
- 94.
- 95. この総合演習の参加資格 • 中級のオブジェクト指向ソフトウェア開発者 • ドメインモデリングの「若干」の知識 •「ドメイン駆動設計」の第１部と第２部の理解 • ハードルは高い • 体験しながら学んでいる • 少しずつ成長ができている手ごたえ
- 96.
- 97. 目指すところ • 何年も変化と成長を続けるソフトウェア • 価値を加え続けるソフトウェア そのために •利用者の活動や関心事を理解し、それを コードで表現することを「優先」する • 学び考える • 深いモデル／しなやかな設計
- 98. モデリングと設計 • 不可分 • オブジェクト指向 •声に出してモデリングする • 言葉に耳を傾ける • ぎこちなさを精査する • 矛盾について熟考する • 文献を読む
- 99. ドメイン駆動設計を実践する • 毎日やる • １年2年と続ける •チームで実践する • 複数のチームで実践する • 体験しながら学び成長を続ける