Domain Driven Design Quickly Online を読んでいく。その4

Domain Driven Design Quickly Online を読んでいく。その1 - 僕とコードとブルーハワイ
 Domain Driven Design Quickly Online を読んでいく。その2 - 僕とコードとブルーハワイ
 Domain Driven Design Quickly Online を読んでいく。その3 - 僕とコードとブルーハワイ
の続き。

読んでいる本
www.infoq.com

今回は「第4章リファクタリングのためのさらに深い洞察」をまとめる。

継続的なリファクタリング

前回は、より良いモデルの作るための姿勢やパターンをまとめた。
今回は、リファクタリングのお話。

リファクタリングとは、アプリケーション動作を変えずにコードの再設計をして改善する作業。

コードのリファクタリングは大事だが、設計段階でのリファクタリングはもっと重要。
設計はモデルの本質を作る作業なので、ドメインとモデルの関係を整理できれば、コードを読むだけでモデルの全体を把握できたりドメインの存在理由がわかるようになる。それに、設計内容は結局コードにも影響してくるため、設計段階での深い考察が重要となってくる。

鍵となる概念を明らかにする

リファクタリングは小さな改善の積み重ね。

ドメインについての深い知識に基づいて、新しい概念や抽象を付け加え、設計の考察を繰り返してより深いモデルにしていく。この作業が小さな改善となる。
これを積み重ねていくと、あるときブレイクスルーが起こり、モデルの見方が変わる。

潜在する新しい概念を見つけるコツ：

モデリングや設計時に使われる言葉に耳を傾ける、つまりユビキタス言語の構築作業をする。構築されたユビキタス言語から概念をあぶり出す。
設計が曖昧な部分を見つけて、足りない概念がないかを探して、設計に反映してみる。
ドメイン構築の際に発生したドメインに対する主張の矛盾を解消する。矛盾の原因は、同じものを別の視点から見ていたり単なる説明不足という場合がある。これを解消することて重要な概念の発見につながるかもしれない。
書籍からドメインについて学ぶ

明確になっていると役に立つ概念：

制約
- 制約とは不変性を表す方法
- もしある概念に制約入れてそれをコードとして書く場合、概念の表現と制約の評価は別のメソッドにしておく方が良い。制約の評価部分のコードを外出しして、概念側ではそのコードを呼び出すという構成。こうすると、制約が明確に表現できるし、制約が増えてもロジックの組み込みが簡単だよねという話。

プロセス
- 手続きによって表現されるものだが、DDDはオブジェクト指向を元にして考えるので、振る舞いを見つけないといけない。つまり、サービスを使う。プロセスをカプセル化して、ストラテジパターンを使う。
- プロセスがユビキタス言語に含まれているなら明確に実装する必要がある。

仕様
- 仕様とはオブジェクトが条件を満たしているかどうか検証する時に使う
- 例えばbool値で検証できるものが一つなら簡単だが、検証のルールが増えるにつれてオプジェクトが肥大化する。そこで仕様のリファクタリングをする。
- 大きくなったルールは、一つの専用のオブジェクトにカプセル化してまとめる。とにかく、いろんなオブジェクトにルールが散らばらないようにする。
- 単純なルールの集まりをオブジェクトにまとめることで、ルールの検証と追加が容易になるし、コードを読むだけで仕様が把握できる。

まとめというか感想

「自動化されたテストは、システムがデグレしてないか・機能が変更されていないか等をチェックするのに役立つ」というような内容あったんだけど、機能が変更されてないけどパフォーマンス的にはデグレってるというのに気づけるようなテストかけてるかな自分、というのが気になった。
要は、システムの要点を洗い出す力があるかどうかという話なんだけど。
仕様が明確ならばテストを書く時にあまり迷わないけど、迷う時は、仕様が曖昧か、ただ単に自分が仕様を正しく理解できていないということになるのだろうなと思う。