# DDD輪読会 II-8
2022/08/18 [@kdnakt](https://twitter.com/kdnakt)
『エリック・エヴァンスのドメイン駆動設計』
---
### 今日の範囲
- 第3部
より深い洞察へ向かうリファクタリング
- 8章ブレイクスルー
---
### 第3部 より深い洞察へ向かうリファクタリング (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~)
- ブレイクスルーで深まったモデル
- 設計をよりわかりやすくする好機
- 暗黙的な概念が明示的に
- 例:トランザクション
- 複雑な抽象概念も単純化
- 例:ポジション
- 開発ペース
- 一般的なプロジェクト:徐々に遅延/停止
- ブレイクスルーしたプロジェクト:加速
{"metaMigratedAt":"2023-06-17T06:47:51.810Z","metaMigratedFrom":"YAML","title":"DDD輪読会 II-8","breaks":"true","slideOptions":"{\"transition\":\"slide\"}","contributors":"[{\"id\":\"df36d0f0-b67e-41ac-96b3-f3988326d230\",\"add\":3116,\"del\":272}]"}