実践に向けたドメイン駆動設計のエッセンス 3

Transcript

• 1. 実践に向けた ドメイン駆動設計のエッセンス 2015年5月27日 増田 亨 有限会社システム設計 代表 ギルドワークス株式会社 取締役
• 2. はじめに
• 3. そんな方々のために、 この本の要点（考え方とやり方）を 実践経験をまじえて紹介します。 そんな方々のために、 この本の要点（考え方とやり方）を 実践経験をまじえて紹介します。 ・読み解くのが困難 ・実践でどう活用するか迷っている ・やってみたがうまくいかない
• 4. 実践してみた • DDD本に出会ってから１０年 • 現場で取り組み始めて８年 –７つの開発プロジェクト –３つのコンサルティング
• 5. 学んだこと •手ごたえ •実践の難しさ •実践していく勘所
• 6. 実践 • 基本に集中して繰り返す –ドメイン駆動設計の基本を理解する –現場でその基本を繰り返す –毎日積み重ねる –１年、2年、3年、… –チームで取り組む –複数のチームで取り組む
• 7. 要点は全部で２８ページ 「まえがき」 ９ページ １部の導入 ４ページ ２部の導入 ２ページ ３部の導入 ５ページ ４部の導入 ２ページ 「結論」 ６ページ
• 8. この２８ページを中心に • 読み解く –わかりにくい言葉を、別の言い方や具 体例で –ドメイン駆動設計とそうでないやり方 と対比 • 体験談に学ぶ –この本が、エバンス自身の体験談 –私の現場での実践
• 9. 今日の旅行日程 • 「まえがき」 から出発 中核の概念 • 第１部の導入 基本用語の説明 – モデル/ドメイン • 「結論」に飛んで、どこを目指しているかを見学 • 「まえがき」に戻って、前提と方向性の確認 – 複雑さという課題 – 設計対開発プロセス – 本書の構成 – 本書が対象とする読者／ドメイン駆動チーム • 第１部の導入から、３つの基本活動を理解する – 知識をかみ砕く／言葉を使う／モデルと実装を結びつける • チームのドメイン駆動設計力を高める体験型の学習 • 総合演習とその実践 モデルの成長のさせ方 ※ 2部、3部、4部は、「本書の構成」と「体験型学習」で触れます
• 10. ドメイン駆動設計の 中核の概念
• 11. 「まえがき」 冒頭の３段落 (ページ xii)
• 12. ドメイン駆動設計の核心 • ドメインモデリングと設計 • オブジェクトコミュニティでの実践 • 設計のイテレーション • 「進化」を続けるドメインモデル • チームで体系的に取り組む
• 13. 中核の概念を 読み解く
• 14. ドメインモデリングと設計 • 不可分 • モデルと設計をいつも関係づける • 同じチームが両方やる • 毎日、モデリングと設計をやる アンチパターン ⇒ モデリングと設計の工程を分ける ⇒ 担当者／チームを分ける
• 15. オブジェクトコミュニティでの 設計とプロセスの良い習慣 • エヴァンスが体験してきたこと –オブジェクト指向開発の先駆者たち –彼らの設計や開発プロセスの「良い習慣」 • ドメイン駆動設計を実践する –その「良い習慣」の基本を理解する –「ドメイン駆動」を軸に関係づける –基本に集中して繰り返す –毎日、チームで
• 16. オブジェクトコミュニティの 良い習慣の参考文献 • ケントベック／マーチンファウラー ドメイン駆動設計を実践する中で、何度も読み返して参考にしている文献 特に「いやな臭い」 「価値」 「原則」が、いつもすばらしいガイド役
• 17. オブジェクト指向ではない世界 • 手続き型プログラミング • 機能分割・工程分割・役割分割 • 技術駆動（計算機駆動） • 自分たちの体に染みついた世界 • オブジェクト指向の道具を使って、 アジャイルを実践しているつもりでも、 手続き型から抜け出せていない 実践の勘所 ⇒ここに気づく ⇒抜け出す努力 ⇒チームで アンチパターン
• 18. 設計のイテレーション • ソフトウェアが動いてからも モデリングと設計を続ける –深いモデルの探求 –しなやかな設計の追求 • なぜ？ –「結論」に書かれた世界を目指す –そのほうが費用対効果が高い
• 19. 「進化」を続ける 豊かなドメインモデル • 成功したプロジェクトに共通する特徴 • ドメイン駆動設計の目指すところ • ８年間やってみて –どういうことか、ようやくわかってきた –その威力を実感し始めている –大きな可能性が見えてきた
• 20. チームで体系的に取り組む • この本を貫く基本の価値観 • チーム – 「言葉」を使って意図を伝達しあう – 「言葉」を使う力は、チームの全員が持っている – この力を磨いてモデリングと設計に活用する • 体系的 – さまざまな活動の有機的なネットワーク構造 – いったりきたりしながら安定する – 変化を繰り返して成長する
• 21. ドメイン駆動設計の核心 • ドメインモデリングと設計 • オブジェクトコミュニティの実践 • 設計のイテレーション • 「進化」するドメインモデル • チームで体系的に取り組む
• 22. 基本用語の理解 モデル ドメイン
• 23. 第１部 ドメインモデルを 機能させる 導入文：冒頭の５段落 (ページ 2,3)
• 24. モデル • 膨大な知識を整理した シンプルでわかりやすい説明 • モデリングのスキル –要約する力 –重要な要素を選び抜く –厳密に組み立てる 実践の勘所 「要約力を磨く」
• 25. ドメイン • ソフトウェアウェアを利用する人た ちの活動と関心事 – ソフトウェアの利用は、活動全体の一部 – 関心事の焦点は、ビジネスや業務上の成果 • ドメインではないこと – ソフトウェアを作る活動 – コンピュータの仕組みや挙動 – 画面仕様書/機能一覧/ユーザーストーリー/…
• 26. ドメインとソフトウェア 利用する人たちの 活動と関心事 ソフトウェア
• 27. ドメインのモデリング • 利用する人たちの「活動」と「関心 事」を要約する • 「活動」の要約 –アクティビティ図／業務フロー図 • 「関心事」の要約 –概念モデル図 （クラス図／パッケージ図）
• 28. 活動の目的／背景 活動の文脈 ソフトウェア 利用する人たちの 活動と関心事
• 29. 活動の文脈のモデリング • 活動の目的や背景の要点を見つける – 「深いモデル」や「コアドメイン」の発見につながる • 情報源 – システム企画書／稟議書 – 事業計画／企業文化 – 経済環境／社会情勢 • コンテキスト図 – 登場人物 – 関連システム – 基本目的の箇条書き
• 30. ドメインモデリング • ドメインモデリングは、ソフトウェアの 外部の世界を学び理解する活動 • 視野を広げる –使う人たちの活動や関心事へ –使う人たちの活動の目的や背景へ • 視野を広げるほうが、ドメインの 理解が楽になる 実践の勘所 ⇒ ドメインをチームで学ぶスキルアップ
• 31. 基本用語 • モデル –シンプルでわかりやすい説明 –「要約」 • ドメイン –ソフトウェアを利用する人たちの 活動と関心事 –活動には目的や背景がある
• 32. ドメイン駆動設計が 目指すところ 506ページから511ページ 「結論」から読み解く
• 33. 「結論」 • 成功とは？ – ドメイン駆動設計は、なにをもって成功なのか • チームに現れる特徴 – ドメイン駆動設計に真剣に取り組むと何がチーム に何がおきるのか • 学び考える – 優れたソフトウェアを作る中核の活動 • 「深いモデル」 「しなやかな設計」
• 34. ドメイン駆動設計の成功 • 何年も成長と変化を続け、 価値をつけ加え続ける –何年にもわたって使われる –豊富な機能を持つ大きなシステム を段階的に成長させる –使う喜び、作る喜び。だから続く。
• 35. チームに現れる特徴 • 対象となるドメインを理解し、 その理解をソフトウェアに具現 化することを「優先」する • ドメインについて学び続ける その結果、いつまでもモデルの 品質には満足できなくなる
• 36. 技術要素の見方が変わる プログラミング 言語 ドメインを理解し それをソフトウェアで表現する そこを優先して考えるようになる フレームワーク 開発ツール プラクティス パターン ドメイン駆動設計にどう使うか？ どのくらい役に立つか？ クラウド リファクタリング
• 37. 学び考える • 優れたソフトウエアを作る核心 • ドメインモデルを探求し、それをソ フトウエアで表現する活動 • チームで学び考える • 「言葉」を使う力を磨き活用する
• 38. ドメイン駆動設計の実践 深いモデル しなやかな設計 そこを目指して チームで学び考える
• 39. 「まえがき」に戻って ドメイン駆動設計の 前提と方向性 xii から xx ページ
• 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. 手続き型のアーキテクチャ プレゼンテー ション層 ビジネス ロジック層 データ ソース層 データの 受け渡し 連想配列/DTO/ 貧血ドメインモデル データの 受け渡し 連想配列/DTO/ 貧血ドメインモデル
• 87. オブジェクト指向のアーキテクチャ プレゼンテー ション層 サービス層 データ ソース層 ドメイン モデル 三層＋ドメインモデル 依頼する （任せる） ドメインオブジェクト を渡す ドメインオブジェクト を渡す オブジェクトと データモデルの 変換装置 オブジェクトと HTTPリクエスト／ レスポンスの 変換装置 参照する 参照する
• 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年と続ける • チームで実践する • 複数のチームで実践する • 体験しながら学び成長を続ける