エリック・エヴァンスの ドメイン駆動設計

P.189～206：第3部冒頭～8章 @福岡DDD勉強会 第7回

すごく、、、AKIMICYUです、、、

第２部から

第３部へ

第２部のおさらい (1/2)モデルと実装との一致を保つための基礎

４章：レイア化アーキテクチャによるドメインの隔離

５章：ソフトウエアで表現されたモデル（エンティティ、値オブジェクト、サービス、モジュール）

６章：集約、ファクトリ、リポジトリ

上記は実証済みの構成要素。矛盾のない言語と一緒に使用することで、開発作業が健全化

そこは本当の課題ではない

第２部のおさらい (2/2)本当の課題は的確なモデルを実際に見つけること

的確なモデルは

ドメインエキスパートの微妙な関心事をとらえて、実用的な設計を推進可能

ドメインについての深い理解をとらえている

第３部では、そうしたモデルの目標を明確にした上で、目標が達成されるまでのプロセスを記述する

第３部： 深い洞察へと向かう リファクタリング

役に立つモデルの成功から導き出せる３点のこと (p.190)

1. 洗練されたドメインモデルを作ることは可能、苦労して実現する価値がある

2. そうしたモデルの開発には、リファクタリングを行うイテレーティブなプロセス（+ドメインエキスパート/開発者の密接な協力）がほぼ必須

3. そうしたモデルは、実装して効果的に使用するにあたって、高度な設計スキルが必要かもしれない

リファクタリング機能を変更しないように行われる、ソフトウェアの再設計プロセス（と著者は捉えている）

リファクタリングについての焦点

1. 「詳細レベルのマイクロリファクタリング」

2. 「パターン試行リファクタリングのアプローチ」

3. 「ドメインについてのより深い洞察」←ここが論点

（１と２が３に置き換わると云っているわけではない。）

深いモデルオブジェクト分析について説明する従来の方法

「要件定義書にある名詞と動詞を識別して、それらをオブジェクト名とメソッド名に採用」

こうして作ったモデルは、浅い知識にしか基づかない

深いモデルはドメインエキスパートの主要な関心事と、それに最も深く関連した知識に関する明快な表現を提供するが、一方でドメインの表面的な側面は捨て去る

注意：ただ抽象化すればいいと云っている訳ではない

各章の位置づけ８章 ブレイクスルー [導入] 成功体験紹介

９章 暗黙的な概念を明示的にする

ドメインの中心となるモデルを探しだす

10章 しなやかな設計 モデルを設計に取り込む方法

11章 アナリシスパターンを適用する 見出した概念のモデル化に

既存のパターンを利用する方法の紹介12章 デザインパターンを

モデルに関連づける

13章 より深い洞察に向かうリファクタリング まとめ

第８章： ブレイクスルー

ブレイクスルーの話(1/4)

リファクタリングの収穫

通常は、小さい努力に対してわずかな報酬

でもたまに、突如として現れて、プロジェクト全体に大きな影響を与えるものがある

→　８章はそういう事例紹介

ブレイクスルーの話(2/4)事例：投資銀行のシンジゲートローン管理

ローン出資、ローン、ファシリティ、出資（p.197）

貸し手の分担率が固定であることを想定していたが、そうでないことが分かってきた

「ローン調整」という概念を導入するもうまくいかず

　　→　基本設計に問題がある兆候では？

ブレイクスルーの話(3/4)「ファシリティの分担率」と「ローンの分担率」が互いに独立して変更できることに気づく

変更前のモデル：分担率から算出された各社のローン出資額について、各社で金額調整を行う。

変更後のモデル：ファシリティ分担率に応じた出資額を負担するかの意思決定を、毎回の出資ごとに各社が行う。その結果としてローンの分担率が確定する

この洞察が大きなブレイクスルー（だが、ビジネスエキスパート視点からは、些細な気づきに時間を浪費しているように見える）

ブレイクスルーの話(4/4)さらに深い洞察

より一般的な「シェアパイ」という概念へ

「シェア算」の導入

「ローン調整」は不要になった

ビジネスエキスパートが理解可能なモデル図になる

新しいユビキタス言語に基づくコミュニケーションの改善が、さらなるモデリングのブレイクスルーに繋がる