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

13章：より深い洞察へと向かう 　　　リファクタリング

@福岡DDD勉強会 第8回

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

1

第3部： 8. ブレイクスルー

9. 暗黙的な概念を明示的にする

10. しなやかな設計

11. アナリシスパターンを適用する

12. デザインパターンをモデルに関係づける

13. より深い洞察へ向かうリファクタリング

前回範囲

今回範囲

今ここ

2

13.より深い洞察へ向かうリファクタリング

要するに、第３部のまとめ（タイトル同じだし）

古典的リファクタリング <-> ドメインリファクタリング(P.190)

ドメインについての洞察を得ようと模索

ドメインリファクタリングの主要なポイント

1. ドメインに馴染む

2. 常に、物事に対して違う見方をする

3. ドメインエキスパートとの対話を途切れさせない

3

リファクタリングの開始コードの問題(複雑さ・ぎこちなさへ)に対応しているうちに、問題の根幹がドメインモデルにあると感じる

古典的リファクタリングの見方から離れることが、ドメインモデルの理解に近づく

より深くドメインを理解した開発者は、モデルをもっと良くする好機を見出す

4

探求チーム(1/2)モデルの洞察には、時間や人手が必要

探求チームのメンバー：

変更を先導する人

開発者（問題解決が得意な人、該当領域の知識が豊富な人、モデリングスキルのある人）

ドメインエキスパート

5

探求チーム(2/2)

探求プロセスのポイント

自主的な意思決定

スコープと休憩

ユビキタス言語の駆使

6

先達の技探求には、さまざまなものが利用可能

ブレインストーミング

ドメインに関する文献、その他情報源

アナリシスパターン（->11章）

デザインパターン（->12章）

数学や述語論理のような一般的形式

7

開発者のための設計

イテレーティブなプロセスにより、開発者は何度も繰り返しコードを変更する

ドメインリファクタリングはしなやかな設計へと繋がるとともに、その恩恵も受ける

しなやかな設計は意図を伝え、開発者の精神的負担を軽減する。良く変更される場所は柔軟になる。

8

タイミング(1/2)変更の完全な正当化を待つのは、待ちすぎ

簡単に見抜けないリスク/コスト

設計をぎこちないままにしておくリスク

その変更をそのままにしておくコスト

ソフトウェア開発は、予測可能なプロセスではない

変更の有無に伴う利益やコストを正確に割り出せない

9

タイミング(2/2)次の場合にはリファクタリングすること

設計が、ドメインに関するチームの現在の理解を表現していない

重要な概念が設計で暗黙的になっている

設計において重要な部分を、よりしなやかにする好機がある

※好きなときに好きな変更をするのを正当化するわけではない

10

好機となる危機ソフトウェアの進化

古典的リファクタリングでは、徐々に安定しつつ進化する（ダーウィンの進化論的）

ドメインリファクタリングでは「断続平衡説」的に進化する。突然ある洞察に導かれ、それによって、あらゆるものが刷新される(->ブレイクスルー)

そうした状況は、一見危機に見える

だが、それはチームの理解レベルが上がったという好機

11

まとめより深い洞察へ向かうリファクタリングは、継続的なプロセス

暗黙的な概念が認識されて明示的になり、設計の一部はよりしなやかになる

開発をしていると突然ブレイクスルーが訪れ、深いモデルへと突き進む

そしてまた、安定した改良が始まる

12

おしまい