3週連続DDDその1 ドメイン駆動設計の基本を理解する
- 1. 第１週 ドメイン駆動設計の基本を理解する 2015年9月2日 増田亨(@masuda220) ギルドワークス株式会社 取締役 有限会社システム設計 代表 ３週連続ＤＤＤ 「ドメイン駆動設計の要点と実践ノウハウ」
- 2. 第１週のアジェンダ • ドメイン駆動設計の「考え方」 「まえがき」を中心に • ドメイン駆動設計の「３原則」 １章から３章 • ドメイン駆動設計の「基本スキル」 ４章から７章
- 3. 第１週の内容を踏まえて • 第２週 「深いモデルの探求」 – モデルと設計の継続的な探求の重要性 – ドメイン駆動設計的なリファクタリング • 第３週 「戦略的に取り組む」 – より広い範囲で長期的に – 誰がやるのか – どうやるのか – いつやるのか
- 4. はじめに
- 7. やってみて • 手ごたえ／おもしろさ • 実践の難しさ • たくさんの読み落とし • たくさんの勘違い • 発見と学習と成長
- 19. オブジェクト指向の「変更容易性」 エクストリームプログラミングの「変化適応性」 • 「エクストリームプログラミング」は「オブジェクト 指向」のコミュニティで生まれ育った • オブジェクト指向の「変更容易性」が、「適応 型」の開発スタイルをささえている • 相互に補強しあう関係 変化に「適応」する技術
- 22. 日々、変化し成長する • 毎日、方向付け/推敲/作成/移行を行う。 – 午前は、「方向付け」と「推敲」のためにコードを書く – 午後は、がっつり「作成」する – 夕方、今日の成果を「配置」する – 毎日フィードバックを受け取る • 最終の着地点と進行方向を確認しながら進む – 何か新しいことが起きていないか、毎日、見直す – 進む方向がずれていないか、毎日、見直す – 週で見直し、季節で見直す • 「変化」を知覚したらチームで機敏に対応する – 方向の微調整かもしれない – おおきな方針転換かもしれない – 変えるべき時は大胆に、チーム一丸で
- 23. YAXP（もうひとつのXP) • 私がもっとも経験してきた開発スタイル – ラフスケッチ一枚と口頭の依頼 – あいまいでふらつく要求／つかまらない担当者 – 動く画面を見せる度に、追加要求と修正依頼 – 「なるはや」リリース – 人「いない」／予算「ない」 – なんでも自分（たち）でやるしかない • 「ドメイン駆動設計」の良い実践の場
- 24. オブジェクト指向の「変更容易性」 エクストリームプログラミングの「変化適応性」 • 「ドメイン駆動設計」の基礎となる設計と開発 の考え方／やり方 • 相互に補強しあう関係 変化に「適応」する技術
- 26. オブジェクト指向の「変更容易性」 (どのパラダイムでも同じだけど） • 抽象データ型／段階的な抽象化 – プログラムを人間の発想に近づけると扱いやすい • モジュラープログラミング – 独立性の高い部品に分けると扱いやすい – 関連するデータと操作は、ひとつのプログラミング単位に • メッセージング – 部品の組合せを柔軟に変更できると扱いやすい – sender/receiver/routing – オブジェクト指向言語でうまく実現できていない • Erlang, EIP:Enterprise Integration Patterns, マイクロ サービス, …
- 27. LocalDate クラス DateOfBirthのインスタンス変数 日付を汎用的に扱う手段 Java APIのレイヤ int year short month short day LocalDateのインスタンス変数 Java言語仕様のレイヤ if( day > 31 ) … DateOfBirth クラス 「誕生日」に用途を限定した独自定義クラス 「ドメイン層」の一級市民（ドメインオブジェクト） 人間の関心事 コンピュータの 仕組み 抽象データ型／段階的な抽象化 人間の発想に近づける Boolean 今月が誕生月() Days 誕生日まであと何日() plusDays() plusMonths()
- 28. OO+XP＝ドメイン駆動設計？ • 「ドメイン駆動設計」は「オブジェクト指向」と 「エクストリームプログラミング」を組み合わせ た開発の体験談 – エクストリームオブジェクト指向プログラミング • 「ドメイン駆動設計」は、ＯＯ＋ＸＰの考え方と やり方の「強調」する点をずらしている by エリック・エヴァンス
- 29. 「ドメイン駆動設計」が強調する点 • 「ドメイン」に焦点をあてる • 「モデル」と「コード」の歩調を合わせながら、 少しずつ「成長」させる • 「言葉」を使って、チームで「モデル」と「設計」 の「改良」を続ける この三つを組み合わせてソフトウェアを開発した体験 談が「ドメイン駆動設計」の特徴であり魅力。
- 30. 「ドメイン駆動設計」の理解の鍵 • 「ドメイン」に焦点を当てるとは、具体的にどう いうことか • 「モデル」と「コード」の歩調を合わせるとは、具 体的にどういうことか • 「言葉」を使って、チームで「モデル」と「設計」を 改良するとは、具体的にどういうことか • そのために「オブジェクト指向」と「エクストリー ムプログラミング」の考え方をどう実践するか
- 32. 「ドメイン駆動設計」の３原則 • 第１章 知識をかみ砕く • 第２章 コミュニケーションと言葉の使用 • 第３章 モデルと実装を結びつける
- 33. ドメイン • ソフトウェアウェアを利用する人た ちの「活動」と「関心事」 – ソフトウェアの利用は、活動全体の一部 – 関心事の焦点は、ビジネスや業務上の成果 • ドメインではないこと – ソフトウェアを作る活動 – コンピュータの仕組みや挙動 – 画面仕様書/機能一覧/ユーザーストーリー/…
- 36. ドメインのモデリング • 利用する人たちの「活動」と「関心 事」を要約する • 「活動」の要約 –アクティビティ図／業務フロー図 • 「関心事」の要約 –概念モデル図 （クラス図／パッケージ図）
- 39. 「ドメインモデル」を育てる • 最初は知識が貧弱な浅い「モデル」から • 「ドメイン（利用する人たちの活動や関心事）」 を学びながら、ドメインの知識を広げ「モデル」 に反映する • 重要な点を残し、些細な点を削りとりながら、 「モデル」を深めていく • 「モデル」と「全体」を並行して育てていく – さまざまな要素の入り組んだ関係を、「モデル」を 中核に整理していく
- 40. ドメイン駆動設計の基本テーマ • 役に立つドメインモデルを「発見的に成長」さ せていく • ドメインモデルの成長に歩調を合わせて、コー ド設計に「ドメインの知識を反映」していく • モデルをコードで実装してみる実験から、「より 役に立つドメインモデル」の手掛りを得る • 「変化」と「成長」を続ける
- 42. 第１章 知識をかみ砕く • プリント基板(PCB)設計ツールの開発経験 • （経験から学んだ）効果的なモデリングの要素 • 知識のかみ砕き • 継続的な学習 • 知識豊富な設計 • 深いモデル
- 43. 「知識をかみ砕く」体験談 • 「知らない」「わからない」からの出発 • 知識の広げながら「モデル」を成長させる • 「役に立つモデル」の発見 – 「ドメイン」をうまく説明できて、かつ、コードで実装 できる「モデル」を探す • 「深いモデル」の発見と利用 – ソフトウェアを利用する人（PCB設計者）の、ものの 見方と重要な関心事への理解を深める – ドメインを深く理解した知識をコードに反映する
- 49. 第１章 まとめ • 知識のないところから出発する • 語彙を増やす • ただしい言い方（正しい意味）を覚える • コードで表現してみる • 本質的な関心事を探求する • 継続的に学ぶ • 知識をかみ砕いた成果が「ドメインモデル」 – 利用する人たちの「活動」と「関心事」の本質を簡潔に 表現した言葉・図・コード
- 51. 第２章 コミュニケーションと言語の使い方 • ユビキタス言語 – 例：貨物輸送プログラム • 声に出してモデリングする • １つのチームに１つの言語 • ドキュメントと図 • 説明のためのモデル
- 52. ユビキタス言語 • いつでも、どこでも、誰とでも – 技術者だけで話あっている時に、「利用する人たちの 関心事」の言葉がでてくれば本物 • 一つ言葉を同じ意味で – 要求仕様や画面に現れる「用語」と、ソフトウェアを利 用する人たちが使う「言葉」の意味の食い違いに注意 • 一つの意味を同じ言葉で – 同じ意味に思える「別の言葉」に敏感に • ユビキタス言語の中で、特に重要な語彙を選び 抜いたものが「ドメインモデル」
- 53. 声に出してモデリングする • 良いモデルを見つける実践的な方法 – 語尾まで明瞭に – しゃべりにくい – 耳障りが悪い • 復唱ゲーム – 同じ言葉、同じ言い回しにならない • 他の表現との不一致に敏感に – コード、図、コミットログ、チャット、メールなど書かれた言葉 – 笑っちゃうくらう一致していない • チームのドメインの理解が進み、要点がはっきりしてくる と、よどみなく同じ言い回しがでてくるようになる
- 54. 一つのチームに一つの言語 • チーム内では一つ言葉を同じ意味で – 要求仕様や画面に現れる「用語」と、ソフトウェアを利 用する人たちが使う「言葉」の意味の食い違いに注意 • チーム内では、一つの意味は同じ言葉で – 同じ意味に思える「別の言葉」に敏感に • 第４部の「境界づけられたコンテキスト」や「継続 的な統合」の基本原理 • エクストリームプログラミングでは、ドキュメントの 代わりに「会話」をする
- 55. 言葉たいせつ • 「エクストリームプログラミング」では、言葉を 使った会話がドキュメントの代わり – 意図伝達の主要な手段 • 「言葉」は、そのままクラス／メソッド／パッ ケージの候補 • あらゆる場所で同じ言葉を – 会話/チャット/メール/コミットログ/ソースコード
- 58. 第３章 モデルと実装を結びつける • モデル駆動設計 • モデリングパラダイムとツールによるサポート • 骨格を見せる：なぜモデルがユーザにとって重 要なのか？ • 実践的モデラ
- 59. モデル駆動設計 ドメイン駆動設計が必要とするモデル • 初期の分析を支援するだけでなく、設計にお いて土台になるモデル • 両方に役に立つモデルを探す – 簡単には見つからない – 最初からは見つからない – 少しずつ実験し、学習し、良いモデルに育てていく – 言葉による実験／コードによる実験
- 60. モデリングパラダイムと使用言語 • オブジェクト指向は、モデリングと実装を一致させること が、考え方の基本にある – 分析クラス＝実装クラス – しかし、理屈通りにはなかなかうまくいかない – そこで「ドメイン駆動設計」 • 手続き型プログラミングは、コンピュータを使ったデータ 操作モデルになりがち – 基本データ型と、その操作命令だけのコード – 人間の考え方に近づける段階的な抽象化の不足 • 「述語論理」と「論理型」プログラミングは一致している – 広くは採用されていない
- 61. （ドメイン層の）骨格を見せる なぜモデルがユーザにとって重要か？ • 「モデル」が、利用者の「重要な関心事」を反映 していれば、主要なクラスとその関係は、利用 者にとって理解できる • ソフトウェアとして表現された「モデル」から、 利用者はソフトウェアの潜在的な可能性に触 れることができる • とんでもない勘違いを発見できる • オブジェクトの構造を画面レイアウトや画面遷 移的に説明すると、会話しやすい
- 64. 第２部 モデル駆動設計の構成要素 • 第４章 ドメインを隔離する • 第５章 ソフトウェアで表現されたモデル • 第６章 ドメインオブジェクトのライフサイクル • 第７章 言語を使用する：応用例
- 65. 第２部 モデルと実装の一致 • モデルと実装の一致は非常に難しい • 何をすべきか – ドメインの隔離 – モデルをコードで表現する – ドメインオブジェクトのライフサイクル – モデル駆動設計のやり方（進め方）
- 66. 第２部は基礎練習 • ボールを蹴って止める基本の練習 • 相手に囲まれても確実にできる • ９０分走りぬいたあとでも確実できる • ぬかるんだピッチでも確実にできる • 第２部の構成要素をどんな状況でも、確実に 使えることが、「第３部 深いモデル」、「第４部 戦略的設計」を実践する土台になる。
- 67. 第４章 ドメインを隔離する • レイヤ化アーキテクチャ • ドメイン層は「モデル」が息づく場所 • 利口なUI（アンチパターン） • その他の隔離
- 68. レイヤ化アーキテクチャ
- 69. ドメインの「隔離」 • ドメイン層を分離 – 表面的な分離は簡単 • 現実 – コントローラ層やページ記述にしみだした業務知識 • if(未承認なら) setDisable() – 複雑なSQL文にまぎれこんだ業務知識 • NOT EXIST xxx OR customer.type = 1 • 業務知識のまぎれこみに敏感になる – アンチパターンを覚える • 継続的にリファクタリングする – 画面が動くと、あらたなビジネスルールが発見され、それをコント ロールや画面で処理するアンチパターンが横行する • データベースのフラグと区分はアンチパターンの宝庫
- 70. ドメイン層 • 「モデル」を表現するのはドメイン層のコードの 一部 – 「重要な関心事」のコードのまわりに、その他の関 心事のコードが集まってくる • ドメイン層にドメインの知識を集め続ける – コードが知識豊富になり、深いモデルの発見の可 能性が広がる – 画面やSQLに書き加えられがちな、ビジネス知識を 丹念に、継続的に、ドメイン層に移動する
- 71. ドメイン層にロジックを集める工夫 • ２ステップビュー • 操作モデルとボタン表示 • 動的SQLの記述 …
- 72. ２ステップビュー • ドメイン層とプレゼンテーション層の関係 • Step1:ドメインオブジェクトが論理構造を返す – 例えば、List<String> • プレゼンテーション層のヘルパークラスが、論 理構造を物理構造に変換する – 例えば、 <tr> </tr>
- 73. 操作モデルとボタン表示 • 状態による操作の違い • ActionList オブジェクトをプレゼンテーション 層に渡す • その情報を元にプレンゼンテーション層が、ボ タンを出し入れする
- 74. 動的SQLの記述 • ドメインオブジェクトに論理構造を持たせる – 動的な AND/OR 条件 – 動的な ORDER BY 句 • データアクセス層のヘルパークラスが、ドメイン オブジェクトが返す論理構造をSQLにマッピン グする
- 75. 第４章のまとめ • ドメインを隔離する • 形式的なコーディングルールや、フレームワークの 導入だけでは、隔離できない • プレゼンテーション層からドメインロジックを抽出し てドメイン層に移動し続ける • データソース層からドメインロジックを抽出してドメ イン層に移動し続ける • ちょっとした修正で、ドメインの知識がドメイン層 以外に拡散する危険を察知する嗅覚を磨く
- 76. 第５章 「モデル」をプログラムで表現する • 関連 • エンティティ • 値オブジェクト • サービス • モジュール • モデリングパラダイム
- 77. 第５章の問題意識 • モデルとコードの一致は難しい • 「モデル」は、人間の関心事の要約 – 「自然言語」で表現する（意図を伝達する） • プログラミング言語という人工言語で、どう、人間 の関心事を表現するか？ – 細かい点に気を配らないと、すぐにモデルと実装が離 れていく – モデル（重要な関心事）と実装が分離すると、ソフト ウェアが的はずれなものになったり、変更がたいへん になる – ソフトウェアの成長が止まる
- 78. モデルをコードで表現する工夫 • スリムな「エンティティ」 • 部品の独立性を高める「値オブジェクト」 • 操作の自然な置き場所を見つける「サービス」 • 重要な関心事「ファーストクラスコレクション」 • ビジネスルールの表現手段「区分オブジェクト」
- 79. ドメイン駆動設計
- 81. 成長を続ける「適応型」アプローチ • ドメインを学びながら「関心事」を発 見する • 「関心事」をクラスに「抽出」しなが ら、モデルとコードの両方を育てる • ドメインの「関心事」を、さらに深 掘っていくとっかかり – 住所がない場合？ – 複数の住所？ – 住所がわかる時／変わる時
- 83. 値オブジェクト（Value Objects) • 大きなクラスの「分割」ではなく、重要な「関心事」 を発見し「抽出」する感覚 • メソッドを「知識豊か」にする手段 – 引数の型／メソッドの返す値の型 × long を渡して String を返す ◎ 「顧客ID」を渡して「住所」を返す • 人間の関心事に近づける努力 – int,String,LocalDateだけでは、ドメインの「関心 事」を具体的に表現できない – 「顧客」や「住所」など、関心事を表現する独自の「型」 を定義する • 抽象データ型／段階的な抽象化
- 84. エンティティ（Entity) • 太りがち – インスタンス変数 – ロジック ⇒概念が暗黙知になりがち • とことんスリムにする – 「識別」という利用者の関心事に集中する • 一覧の表示順や検索項目 • 特に関心があることの発見 – 「内容を説明」する関心事は「値オブジェクト」にま かせる（別の議論にする）
- 85. ドメイン層のサービス • どの「エンティティ」や「値オブジェクト」に置くべ きか迷うロジックがいろいろでてくてる • そういう時は、そのロジックに名前を付けてク ラスとして抽出してみる（実験） – XxxPolicy – XxxRule – XxxProcedure …
- 86. ドメイン層のサービス 危険！ • 「手続き」にドメインの「関心事」が隠ぺいされがち – 深いモデルの探求の手掛りを見失う • 同じ「ロジック」が複数サービスに重複しがち – 変更コストがあがる – モデルとコードの成長の障害になる • 考え方とやり方 – メソッドの引数と型は「ドメインオブジェクト」にする • long や Stringを使わない – 基本は多態（ルールの場合ごとの切り替え）の道具 – それ以外の場合、リファクタリングの候補としておく • より適切な置き場所を模索することで、良いモデルを探求
- 88. ファーストクラスコレクション • コレクションをラップしたドメインオブジェクト • Products • PurchaseHistory • 「一覧」や「履歴」を表現したオブジェクト – 一覧画面などに対応するドメインオブジェクト – 「一覧」に関する利用者の関心事のモデル • SQL文の複雑な問合せでがんばる？ – SQLの抽出条件は単純にして、微妙な抽出や問合せ を、オブジェクトにやらせる、というのも選択肢 – どちらが、ドメインの概念をうまく表現するか – 変更があった時に、どちらが楽で安全か
- 89. 区分オブジェクト • 振る舞いを持った Enum • 区分ごとのロジックを別クラスに記述 • Java言語使用に組み込まれた Strategy/Stateパターン 説明とコード例は、googleで 「場合わけの書き方あれこれ」で検索。 または「ソフトウェアデザイン９月号」 場合ごとのルールを理解し表現する工夫
- 90. モジュール(Packages) • 重要なモデリング要素 – 関連するドメインオブジェクト（の型）のグループ – 利用者の関心事の「境界」を表現する手段 – プログラミング単位 – テスト単位 • 「適応型」のアプローチの対象 – 新しい発見とともに、積極的にパッケージ名／ パッケージ構成を変更し育てていくこと • 「第４部 戦略的設計」の主要ツール
- 91. モデリングパラダイム • このテーマが「第５章 ソフトウェアで表現された モデル」に登場する意味 – 「モデリングの考え方」と「実装の考え方」 – 基本が同じであれば、モデルをコードで表現しやすい – 分析クラス＝実装クラス • 「モデル」と「実装」の歩調を合わせて育てていく これがやりやすいパラダイムは？ – モデリングの原則と実装の原則の歩調を合わせやす い – モデリングの実践スタイルと実装の実践スタイルの歩 調を合わせやすい – モデルの変更と実装の変更の歩調を合わせやすい
- 92. オブジェクトパラダイム • エヴァンスが取り組んだこと（この本はその体験談） • オブジェクトの世界におけるオブジェクトではないもの – 述語論理(AND/OR/NOT/EXIST) – 複雑な数学計算 – 関係データベース • パラダイムを混在させる際にはモデル駆動設計に忠実 であること – 実装パラダイムと対立しない（違いを正しく理解する） – ユビキタス言語を使って統合性を保つ – UMLにこだわらない – パラダイムの混在は懐疑的に（メリットよりデメリットを重く）
- 93. 第５章のまとめ • ソフトウエアで表現したモデル • 「モデル」と「実装」の一致は難しい • そのための基本スキルを体で覚える • 丁寧に地道に続ける • 第３部、第４部の土台 – ほんとうに役に立つのは深いモデルを見つけた時 – 大きな効果がでるのは戦略的に取り組んだ時
- 94. 第６章 ドメインオブジェクトのライフサイクル • 集約 • ファクトリ • リポジトリ
- 95. 第６章の問題意識と解決の工夫 • 複雑になりがちな箇所 – オブジェクトのライフサイクル管理 • 生成／格納・再構成／修正／削除 – オブジェクト間の整合性の管理 • 「モデル」をこの複雑さから守るために – ドメインオブジェクトのネットワーク構造と「集約」 – オブジェクトの生成と「ファクトリ」 – 必要なオブジェクトを簡単に入手する「リポジトリ」
- 96. 「集約」 • ドメインオブジェクトのネットワーク構造 – 利用者の「活動」や「関心事」の結びつきを反映す るので、必然的に複雑になる • 「集約」という単位を導入して、複雑なネット ワークに「構造」を導入する（設計上の問題） – 「ひとかたまり」として扱うべき境界を探す – 言語仕様上に表現手段がないのが難点
- 97. 「ファクトリ」 • オブジェクト（の集約）の生成 – エンティティ（集約のルート）が自分で持つと、エンティ ティ本来の関心事があいまいになる – 「コード」が複雑になり「モデル」との対応があいまいに なる • 生成ロジックの置き場所 – 「集約のルート」のファクトリメソッド – 「集約の生成」に関わるオブジェクトのファクトリメソッド – コンストラクタ – 独立したファクトリクラス …
- 98. 「リポジトリ」 • 必要なオブジェクトの集約を入手する • あたかもすべてのドメインオブジェクトがメモリ 上にあるように設計する – データベース設計やORマッピングをいったん忘れる – interface 宣言で実装を分離する • やりたいことをシンプルに宣言する • 注文 findBy(管理番号) • 注文一覧 lookFor(検索条件) • void register(注文)
- 99. 第６章の補足（実践例） • 注文Repository#prototype() – データベースのシーケンスを使った管理番号を持ったド メインオブジェクトの生成 – 注文受付番号を持ったドメインオブジェクトを返す – 入力画面に渡す – デフォルト値の設定 • 「トランスファ」インタフェース – 「通知」を表現するモデル要素 – 「記録・参照」を表現した「リポジトリ」と似ている – 実現手段は、データアクセス層で実装する
- 100. 第７章 言語を使用する：応用例 • ４章、５章、６章の「構成要素」を組み合わせ る実戦に近い練習 • 仮想的なチームが要求と実装の問題に対処し ながら「モデル駆動設計」で開発をしていく例 • その過程で生じる「さまざまな問題」と「どう解 決」されるかを見ていく • 読み取るのはたいへんだが、発見と学びが多 い章
- 101. 第７章の構成（流れ） 1. 貨物輸送システムの概要 2. ドメインを隔離する：アプリケーション層の導入 3. エンティティと値オブジェクトを区別する 4. 輸送ドメインの「関連」を設計する 5. 「集約」の境界 6. 「リポジトリ」を選択する 7. シナリオをウォークスルーする 8. オブジェクトの生成 9. リファクタリングのために立ち止まる 10.輸送モデルにおける「モジュール」 11.新機能を導入する：配分チェック 12.最後に
- 102. 第７章はより実戦に近い練習 • 「モデル」と「実装」が育っていく過程とリズム • 「モデル駆動」で設計するということ – まず「アプリケーション層」を導入する • 「ドメイン層」の議論を「機能」視点から隔離する • 機能（処理）の詳細化からの設計ではない – 入出力項目（画面帳票）の定義は登場しない • プレゼンテーション層無しのドメイン層の設計と実装 – データモデル／テーブル設計は登場しない • データモデルから独立したドメイン層の設計と実装
- 103. 関連・集約・リポジトリ • 第７章の議論のハイライト • 「関連」を設計する – 関連の方向の議論はドメインに対する洞察 – 複雑な実装を避ける（成長容易性の確保） • 「集約」の境界 – ドメインオブジェクトの「かたまり」の定義 – 概念（関心事）の境界の明確化 – 開発単位 • 「リポジトリ」を選択する – 機能視点が登場するタイミング • 検索／選択／登録 …
- 104. ３週連続 DDD 第１週のまとめ
- 106. 「ドメイン駆動設計」が強調する点 • 「ドメイン」に焦点をあてる • 「モデル」と「コード」の歩調を合わせながら、 少しずつ「成長」させる • 「言葉」を使って、チームで「モデル」と「設計」 の「改良」を続ける この三つを組み合わせてソフトウェアを開発した体験 談が「ドメイン駆動設計」の特徴であり魅力。
- 107. 「ドメイン駆動設計」の理解の鍵 • 「ドメイン」に焦点を当てるとは、具体的にどう いうことか • 「モデル」と「コード」の歩調を合わせるとは、具 体的にどういうことか • 「言葉」を使って、チームで「モデル」と「設計」を 改良するとは、具体的にどういうことか • そのために「オブジェクト指向」と「エクストリー ムプログラミング」の考え方をどう実践するか
- 109. モデルと実装を一致させ続ける • モデルと実装の一致は非常に難しい • やるべきこと – ドメインを隔離し続ける – モデルを的確にコードで表現する工夫を続ける – ドメインオブジェクトの複雑化を防ぎ続ける • 発見と学習と成長を続ける – ドメインの知識 – 深いモデル – 実装に役立つモデル
- 110. ボールを蹴って止める練習 • スリムな「エンティティ」 • 部品の独立性を高める「値オブジェクト」 • 操作の自然な置き場所を見つける「サービス」 • 重要な関心事「ファーストクラスコレクション」 • ビジネスルールの表現手段「区分オブジェクト」 • オブジェクトのネットワーク構造に切り込む「集約」 • 生成を切り離して扱う「ファクトリ」 • 全てはメモリ上にあるかのように「リポジトリ」
- 111. 第１週の内容を踏まえて • 第２週 「深いモデルの探求」 – モデルと設計の継続的な探求の重要性 – ドメイン駆動設計的なリファクタリング • 第３週 「戦略的に取り組む」 – より広い範囲で長期的に – 誰がやるのか – どうやるのか – いつやるのか
- 112. 最後に
- 113. • どんな状況でも改善できる • どんなときでも「あなた」から改善を始められる • どんなときでも「今日」から改善を始められる エクストリームプログラミングの 「はじめに」に記された ケント・ベックのメッセージ