ドメインオブジェクトの設計を段階的に改善する

現場で役立つシステム設計を読んだので覚えておきたいことをメモしました。

組み合わせながら改善するポイントは以下３つ

• クラス名やメソッド名の変更
• ロジックの移動
• 取りまとめ役のクラスの導入

クラス名やメソッド名の変更

最初は妥当だったものが他のオブジェクトから実際に使ってみると、収まりが悪いことがある。
その場合は、クラス名やメソッド名を変更して、より自然に使える部品に改良する。
意図の違いがより明確になる名前に変えたり、抽象度を揃える名前に変える。

ロジックの移動

ドメインオブジェクトは仕事を任せるための部品。ドメインオブジェクトを使っているのにごちゃごちゃしてきたら、それは部品側にロジックを移動すべき明らかな兆候である。

取りまとめ役のクラスの導入

ドメインオブジェクトの最小単位は１つの数値/日付/文字列をラッピングした値オブジェクトだが、業務の関心ごとの粒度としては少し小さすぎる。
業務の主たる関心ごとはもう少しまとまった単位で、例えば住所。
値オブジェクトとしては郵便番号クラス、市区町村クラス、街区クラス、番地クラスなどにクラスなどに分けることはできる。しかし、業務の主たる関心ごとはそれを組み合わせた住所クラス。このように最小単位のドメインオブジェクトをいくつか組み合わせたクラスが業務の主たる関心ごとになる。

業務の言葉とコードと一致させると変更が楽になる

開発者の業務知識が貧弱なまま設計したドメインオブジェクトは的外れなものになる。

• クラス名が問題領域の関心事の用語と一致している
• メソッド名が利用者が知りたいこと/やって欲しいことと一致している

ドメインモデルを構成するオブジェクトをこのように設計することで、ソフトウェアは変更しやすくなる。

• どこに何が書いてあるのか特定しやすい
• 変更の対象のクラスが変更の要求の範囲と一致している
• 変更の影響するソフトウェアの範囲が、変更が関連する業務の範囲と一致する

また、業務の関心事をプログラミング言語で記述することで、プログラムの側から、問題領域を深く理解する手がかりが見つかることがある。

• 同じことを複数の業務用語で表現しているあいまい性
• １つの業務用語が使う文脈で異なる意図を持つあいまい性
• 業務ルール間の矛盾の発見
• 込み入った微妙な関心事の整理の軸