エリック・エヴァンスの ドメイン駆動設計 P.189~206:第3部冒頭~8章 @福岡DDD勉強会 第7回 すごく、、、AKIMICYUです、、、
Jun 30, 2015
エリック・エヴァンスの ドメイン駆動設計
P.189~206:第3部冒頭~8章 @福岡DDD勉強会 第7回
すごく、、、AKIMICYUです、、、
第2部から
第3部へ
第2部のおさらい (1/2)モデルと実装との一致を保つための基礎
4章:レイア化アーキテクチャによるドメインの隔離
5章:ソフトウエアで表現されたモデル(エンティティ、値オブジェクト、サービス、モジュール)
6章:集約、ファクトリ、リポジトリ
上記は実証済みの構成要素。矛盾のない言語と一緒に使用することで、開発作業が健全化
そこは本当の課題ではない
第2部のおさらい (2/2)本当の課題は的確なモデルを実際に見つけること
的確なモデルは
ドメインエキスパートの微妙な関心事をとらえて、実用的な設計を推進可能
ドメインについての深い理解をとらえている
第3部では、そうしたモデルの目標を明確にした上で、目標が達成されるまでのプロセスを記述する
第3部: 深い洞察へと向かう リファクタリング
役に立つモデルの成功から導き出せる3点のこと (p.190)
1. 洗練されたドメインモデルを作ることは可能、苦労して実現する価値がある
2. そうしたモデルの開発には、リファクタリングを行うイテレーティブなプロセス(+ドメインエキスパート/開発者の密接な協力)がほぼ必須
3. そうしたモデルは、実装して効果的に使用するにあたって、高度な設計スキルが必要かもしれない
リファクタリング機能を変更しないように行われる、ソフトウェアの再設計プロセス(と著者は捉えている)
リファクタリングについての焦点
1. 「詳細レベルのマイクロリファクタリング」
2. 「パターン試行リファクタリングのアプローチ」
3. 「ドメインについてのより深い洞察」←ここが論点
(1と2が3に置き換わると云っているわけではない。)
深いモデルオブジェクト分析について説明する従来の方法
「要件定義書にある名詞と動詞を識別して、それらをオブジェクト名とメソッド名に採用」
こうして作ったモデルは、浅い知識にしか基づかない
深いモデルはドメインエキスパートの主要な関心事と、それに最も深く関連した知識に関する明快な表現を提供するが、一方でドメインの表面的な側面は捨て去る
注意:ただ抽象化すればいいと云っている訳ではない
各章の位置づけ8章 ブレイクスルー [導入] 成功体験紹介
9章 暗黙的な概念を明示的にする
ドメインの中心となるモデルを探しだす
10章 しなやかな設計 モデルを設計に取り込む方法
11章 アナリシスパターンを適用する 見出した概念のモデル化に
既存のパターンを利用する方法の紹介12章 デザインパターンを
モデルに関連づける
13章 より深い洞察に向かうリファクタリング まとめ
第8章: ブレイクスルー
ブレイクスルーの話(1/4)
リファクタリングの収穫
通常は、小さい努力に対してわずかな報酬
でもたまに、突如として現れて、プロジェクト全体に大きな影響を与えるものがある
→ 8章はそういう事例紹介
ブレイクスルーの話(2/4)事例:投資銀行のシンジゲートローン管理
ローン出資、ローン、ファシリティ、出資(p.197)
貸し手の分担率が固定であることを想定していたが、そうでないことが分かってきた
「ローン調整」という概念を導入するもうまくいかず
→ 基本設計に問題がある兆候では?
ブレイクスルーの話(3/4)「ファシリティの分担率」と「ローンの分担率」が互いに独立して変更できることに気づく
変更前のモデル:分担率から算出された各社のローン出資額について、各社で金額調整を行う。
変更後のモデル:ファシリティ分担率に応じた出資額を負担するかの意思決定を、毎回の出資ごとに各社が行う。その結果としてローンの分担率が確定する
この洞察が大きなブレイクスルー(だが、ビジネスエキスパート視点からは、些細な気づきに時間を浪費しているように見える)
ブレイクスルーの話(4/4)さらに深い洞察
より一般的な「シェアパイ」という概念へ
「シェア算」の導入
「ローン調整」は不要になった
ビジネスエキスパートが理解可能なモデル図になる
新しいユビキタス言語に基づくコミュニケーションの改善が、さらなるモデリングのブレイクスルーに繋がる