１３章は第三部の落ち葉拾い的なトピックですが、ドメイン駆動設計の「より深い洞察へ向かうリファクタリング」あるあるが詰めこられていて、これが出来ていると実感できれば、良い設計になっている基準とすることもできそう。
リファクタリングのきっかけはさまざま
- 問題の根源がドメインモデルにあると感じる
- ドメインエキスパートと切り離されているように見える
- 新しい要求が自然には適合せず、ドメインモデルが間違っている
- 学習の結果リファクタリングが必要となる
探求チーム
新しいモデルを模索する方法。
開発者数人でのブレインストーミングを行う。UMLのスケッチやオブジェクトを使用してシナリオのウォークスルーも効果的。
その後、数日寝かして、自信を持って結論に至る。
この数日寝かしてというのがミソですよね。一度にやることで行き詰まることもある。寝かして新たな気付きがあることは多いですよね。
タイミング
変更を完全に正当化できるまで待つのは、待ちすぎというものである。(第三部・第十三章より)
継続的なリファクタリングに関して、依然としてほとんどのプロジェクトで慎重過ぎるとEvansは言っています。実感としても、そのように感じますね。
この本が書かれたのは2003年と10年以上前ですが、現在でも変わりませんね。
プロジェクトが落ち着いてからリファクタリングしようとかいうチームは未だ多いのではないでしょうか。
コードを変更するリスクと、変更にかかる開発者の時間のコストとそれに見合ったリターンがあるかなどを考慮しているのでしょうが、ソフトウェア開発はそのようなコスト・利益を予測できるプロセスではないとEvansも言っていますし、そう思います。
リファクタリングするタイミング
- 設計が、ドメインに関するチームの現在の理解を表現していない
- 重要な概念が設計で暗黙的になっている(かつそれを明示的にする方法がわかっている)
- 設計において重要な部分を、よりしなやかにする好機がある。 (第三部・第十三章より)
リファクタリングしないとき
- リリース前日
- 技術的なリファクタリングしかしないとき(Evansはこれを括弧つきの「しなやかな設計」と呼んでいます)
例えば、第十ニ章 デザインパターンをモデルに関係づけるで 紹介したドメインの概念に合わせることを考えずに複雑なデザインパターンを適用するようなケース。これは、結局ソースコードが複雑になるだけですよね。
ブレイクスルーがおきるとき
継続的なリファクタリングは少しずつ改良していくのがセオリーであり、それは変わらないのですが、リファクタリングの途中で、突然ある洞察へと導かれ、あらゆるものが刷新されるようなブレイクスルーが起きる時があります。
深いモデルとしなやかな設計につながる変更の大部分はそこから現れるといいます。
はっきりこの時だ！と説明できる例がないのですが、なんとなく経験あります。リファクタリングした結果、これってこうした方がいいんじゃない？ということが起こり、そこからあちこちモデルがはっきりしていくということが確かにあります。
そうした状況は好機に見えないとEvansが言っているのは、今のモデルがはっきりと間違っていると分かった状況だからですね。
プロジェクト進行中にこうしたブレイクスルーが起こったことが自覚できたとき（もちろん毎日起こることではないです)、今のやり方が合っているんだと思える瞬間ではないでしょうか。
明日からは最終第四部！！！(ここからが大変)