# DDD輪読会 II-8 2022/08/18 [@kdnakt](https://twitter.com/kdnakt) 『エリック・エヴァンスのドメイン駆動設計』 --- ### 今日の範囲 - 第３部 より深い洞察へ向かうリファクタリング - 8章ブレイクスルー --- ### 第３部 より深い洞察へ向かうリファクタリング (p.190~) - 真の課題：的確なモデルをいかに見つけるか - ドメインエキスパートの考え方に一致 - ユーザの要望にうまく対応 - 役に立つモデルの開発に不可欠なもの - 反復的なリファクタリングプロセス - 開発者/ドメインエキスパートの密な協力 - 高度な設計スキル ---- #### リファクタリングのレベル(p.190~) - 一般的なリファクタリング - 機能を変更しないソフトウェアの再設計 - 設計をより柔軟に、理解しやすくする - コード自体の問題に基づくもの - システムの活力に最も大きく影響する リファクタリング - ドメインの新たな洞察に基づくもの - モデルをより明確、深く表現するもの ---- #### 深いモデル(p.191~) - 従来のオブジェクト分析 - 名詞と動詞をオブジェクトとメソッドに - 表面的で浅い知識に基づくモデル - 深いモデル - ドメインの表層的な側面は捨て去る - ドメインエキスパートの関心事に関する明確な表現を提供 - 例)船舶輸送アプリケーションのモデル - 初期版：船舶、コンテナ、荷積み、 荷下ろし、... - 最終版：輸送機器の運行、船荷証券、... ---- #### 深いモデル/しなやかな設計(p.193~) - しなやかな設計＝第10章のテーマ - 変更を容易にする設計 - システムの他の部分と統合しやすくする設計 - 恒常的なリファクタリングを 繰り返すことで近づける - よく変更される場所＝柔軟な場所 ---- #### 発見のプロセス(p.193~) - ドメインの中心概念をとらえる - 第9章「暗黙的な概念を明示的にする」 - 第10章「しなやかな設計」のソフトウェア - 継続的リファクタリングでモデリング - 拡張や変更の際に、生産性が向上する - 発見した概念をモデル化するために - 第11章「アナリシスパターン」 - 第12章「デザインパターン」 - より深い洞察へ：第8章「ブレイクスルー」 - ソフトウェアを表現力豊かにする機会 --- ### 第8章 ブレイクスルー(p.195~) - ブレイクスルーの話 - 好機 - 基本への集中 - エピローグ：新しい洞察の連鎖 ---- - リファクタリング - 小さい努力・改良でレガシー化を防ぐ - 時に重要な洞察が全体に衝撃を与える - 継続的なリファクタリング - 不規則な発展が生まれる可能性 - 開発者の視界が明確になり、 ブレイクスルーの可能性高まる - ブレイクスルー - ユーザーの要求とモデルが ハイレベルに一致する - テクニックでなく出来事 ---- #### ブレイクスルーの話(p.196~) - 投資銀行の巨大なローン管理アプリ - 複数の融資会社によるシンジケート ---- ##### 悪くないモデルなのだが...(p.197~) - 単純化したモデル - ファシリティ（融資の確約）と 出資(分担率) - ローンとローン出資(分担率) - 予想外の要求 - ローン出資は出資に必ずしも比例しない - ローン調整という概念の導入 - 丸めによる微妙な不整合の問題 ---- ##### ブレイクスルー(p.198~) - モデルの問題点が「降って」きた - 出資とローン出資を 結びつける必要はない！ - ビジネスエキスパートと新しいモデルの議論 - 手数料と金利の配分問題も解決 ---- ##### さらに深いモデル(p.201~) - 2つの別々の概念「出資」と「ローン」？ - 本質的に同じ概念だという洞察 - 「分担率(シェア)」 - あらゆる取引をシェアで計算可能に - 不要な機能、ロジックを大量に削除 - ビジネスエキスパートが完全理解できるシナリオ - 上手く行きそう - だけど... ---- ##### 冷静な意思決定(p.203~) - 恐怖が支配する - 新しいモデル導入に多くの変更が必要 - 小さな改善の途中、アプリが使用不可 - テスト自動化はされていない - PjMとのMTG - 新しいモデルが必要な状況を正確に報告 - PjMを信頼し、必死で取り組む ---- ##### 結末(p.204) - 予期せぬ要求変更は無くなった - 次期バージョンへの道も明確になった - 関係者がユビキタス言語で議論する - 技術者とビジネスエキスパート - 販売担当と見込み客 --- #### 好機(p.204) - ブレイクスルー≒恐怖を感じる - チャンスも多いが、リスクも大きい - 発想の転換には設計の大幅な変更が必要 --- #### 基本への集中(p.204~) - ブレイクスルー≠意図的に起こせるもの - 適度なリファクタリングの継続が不可欠 - 強固なユビキタス言語の育成 - 重要なドメインの概念の探求（cf.第9章） - しなやかな設計の追求（cf.第10章） - モデルの蒸留（cf.第15章） --- #### エピローグ：新しい洞察の連鎖(p.205~) - ブレイクスルーで深まったモデル - 設計をよりわかりやすくする好機 - 暗黙的な概念が明示的に - 例：トランザクション - 複雑な抽象概念も単純化 - 例：ポジション - 開発ペース - 一般的なプロジェクト：徐々に遅延/停止 - ブレイクスルーしたプロジェクト：加速