目標
・ふわっとした理解のDDDについてエヴァンス本を通して体系的に学習する
・各章の要約をアウトプットすることで知識を定着させる
前回の記事
第12章の内容は以下でまとめています。
【第13章】より深い洞察へ向かうリファクタリング
より深い洞察へ向かうリファクタリングは多くの側面をもつプロセスである。
主要なポイントは以下の3つだ。
・ドメインに馴染む
・物事に対して常に違う見方をする。
・ドメインエキスパートとの対話を途切れさせない。
開始
リファクタリングに対する従来の見方を変え、コードのぎこちなさや複雑さの根源はドメインモデルにあると考える。
ドメイン知識を身につけ、より深くドメインを理解するようになると、モデルを改善したり役立つように改修するきっかけとなる。
研究チーム
次の段階は、意図を明確かつ自然に伝達するようなモデルに改良する方法を探すこと。
このプロセスを生産的にするポイント3つ。
・自主的な意思決定
少数精鋭でチームを組む。(長期的な組織構造は不必要)
・スコープと休憩
数日の感覚を空けて短いMTGを2~3回することで、価値のある設計が作れる。
・ユビキタス言語の駆使
他チームやドメインエキスパートとのMTGではユビキタス言語を駆使することでモデル改良の機会が生まれる。
先達の技
ドメインに関する文献や別の情報源から、モデルに対して役立つ概念を見つけることで
知識を噛み砕くプロセスの糧にする。
開発者のための設計
しなやかな設計を意識することで、依存関係と副作用が抑制され、変更したコードの実行結果が予想しやすくなる。
結果的に開発者の精神的過負荷を制限することにつながる。
タイミング
ソフトウェア開発は、変更することで得られる利益や、変更しないことで生じるコストを
正確に割り出せるような予測可能なプロセスではないため
ドメインに関する継続的な研究やドメインエキスパートとの会話を続けなければならない。
具体的には次の場合にリファクタリングを行う。
・設計がドメインに関する理解を表現していない。
・重要な概念が設計で暗黙的になっている。
・設計の重要な部分をよりしなやかにする好機がある。
逆に以下の場合にリファクタリングを避ける。
・リリース前日。
・技術的なアピール目的。
・ドメインエキスパートに理解されてない。
好機となる危機
より深い洞察へ向かうリファクタリングは継続的なプロセスであるため
突然ドメインに対するブレイクスルーが起きて古いモデルは貧者に見え、危機的に見えるかもしれないが
この視点があればはるかに優れたモデルを思いつくことができる。
まとめ
本章ではしなやかな設計を前提としたリファクタリングのプロセスを学ぶことができた。
これで第3部は終了になるが、ソフトウェアは継続して改善し刷新していくことで価値を生むことができる
という考え方が印象的だった。
今後作るプログラムは保守しやすい設計を心がけるとともに、これまでの作ってきたプログラムに対しては
改善できる箇所がないか目を向けることが大事だと感じた。
次は「第４部戦略的設計」から「第14章モデルの整合性を維持する」を学んでいく。
参考になったらいいねやコメントおまちしています！！