Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

23,209 views

Published on

ドメイン駆動設計

  • Be the first to comment

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

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

×