第7回福岡DDD勉強会の発表資料です。 本勉強会は「エリックエヴァンスのドメイン駆動設計」の読書会をしたり、実際に手を動かしたりといったことを通してDDD、モデリングについて勉強する集まりです。

1. エリック・エヴァンスの
ドメイン駆動設計
P.189～206：第3部冒頭～8章
@福岡DDD勉強会 第7回
すごく、、、AKIMICYUです、、、

2. 第３部へ
第２部から

3. 第２部のおさらい (1/2)
モデルと実装との一致を保つための基礎
４章：レイア化アーキテクチャによるドメインの隔離
５章：ソフトウエアで表現されたモデル（エンティ
ティ、値オブジェクト、サービス、モジュール）
６章：集約、ファクトリ、リポジトリ
上記は実証済みの構成要素。矛盾のない言語と一緒に使
用することで、開発作業が健全化
そこは本当の課題ではない

4. 第２部のおさらい (2/2)
本当の課題は的確なモデルを実際に見つけること
的確なモデルは
ドメインエキスパートの微妙な関心事をとらえて、実
用的な設計を推進可能
ドメインについての深い理解をとらえている
第３部では、そうしたモデルの目標を明確にした上で、
目標が達成されるまでのプロセスを記述する

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

6. 役に立つモデルの成功から導き出せる
３点のこと (p.190)
1. 洗練されたドメインモデルを作ることは可能、苦
労して実現する価値がある
2. そうしたモデルの開発には、リファクタリングを
行うイテレーティブなプロセス（+ドメインエキ
スパート/開発者の密接な協力）がほぼ必須
3. そうしたモデルは、実装して効果的に使用するに
あたって、高度な設計スキルが必要かもしれない

7. リファクタリング
機能を変更しないように行われる、ソフトウェアの再設計
プロセス（と著者は捉えている）
リファクタリングについての焦点
1. 「詳細レベルのマイクロリファクタリング」
2. 「パターン試行リファクタリングのアプローチ」
3. 「ドメインについてのより深い洞察」←ここが論点
（１と２が３に置き換わると云っているわけではない。）

8. 深いモデル
オブジェクト分析について説明する従来の方法
「要件定義書にある名詞と動詞を識別して、それらをオブジェ
クト名とメソッド名に採用」
こうして作ったモデルは、浅い知識にしか基づかない
深いモデルはドメインエキスパートの主要な関心事と、それに
最も深く関連した知識に関する明快な表現を提供するが、一方
でドメインの表面的な側面は捨て去る
注意：ただ抽象化すればいいと云っている訳ではない

9. 各章の位置づけ
８章ブレイクスルー[導入] 成功体験紹介
９章暗黙的な概念を
明示的にする
ドメインの中心となる
モデルを探しだす
10章しなやかな設計モデルを設計に取り込む方法
11章アナリシスパターンを
適用する見出した概念のモデル化に
既存のパターンを利用する
12章デザインパターンを方法の紹介
モデルに関連づける
13章より深い洞察に向かう
リファクタリングまとめ

10. 第８章：
ブレイクスルー

11. ブレイクスルーの話(1/4)
リファクタリングの収穫
通常は、小さい努力に対してわずかな報酬
でもたまに、突如として現れて、プロジェクト
全体に大きな影響を与えるものがある
→ ８章はそういう事例紹介

12. ブレイクスルーの話(2/4)
事例：投資銀行のシンジゲートローン管理
ローン出資、ローン、ファシリティ、出資（p.197）
貸し手の分担率が固定であることを想定していたが、
そうでないことが分かってきた
「ローン調整」という概念を導入するもうまくいかず
→ 基本設計に問題がある兆候では？

13. ブレイクスルーの話(3/4)
「ファシリティの分担率」と「ローンの分担率」が互いに
独立して変更できることに気づく
変更前のモデル：分担率から算出された各社のローン出
資額について、各社で金額調整を行う。
変更後のモデル：ファシリティ分担率に応じた出資額を
負担するかの意思決定を、毎回の出資ごとに各社が行
う。その結果としてローンの分担率が確定する
この洞察が大きなブレイクスルー（だが、ビジネスエキスパート視点から
は、些細な気づきに時間を浪費しているように見える）

14. ブレイクスルーの話(4/4)
さらに深い洞察
より一般的な「シェアパイ」という概念へ
「シェア算」の導入
「ローン調整」は不要になった
ビジネスエキスパートが理解可能なモデル図になる
新しいユビキタス言語に基づくコミュニケーションの改善が、
さらなるモデリングのブレイクスルーに繋がる