ダイコン時代の設計手法 - ロジックをどこに置くのか
そうなのかっと感心するとともに、実は当惑…。データとそのデータを扱う処理をひとつのものとして扱うのがオブジェクト指向設計であり、保守を容易にするにはそれを目指すべきだと思い込んでいました。
これはもちろん真実だと思います。しかし、次の重要な点が
関連のあるデータと振る舞いを1つに集めることで、
凝集度を上げ結合度を下げることよって保守が容易になる
これまでは語られていないんじゃないかと思います。
これによって上記の言葉は次のように言い換えられると思います。
振る舞いは最も結びつきの高いオブジェクトにおくべきだ
業務ロジックは次のように分解されます。
データとそのデータに最も結びつきの高い振る舞いを1つに集めることで、
凝集度を上げ結合度を下げることよって保守が容易になる
- ユースケース固有
- 永続化
- 共通
ユースケース固有のロジックはエンティティに含めるべきでしょうか?
エンティティに最も結びつきが強いと果たして言えるでしょうか?
例えば、手数料というエンティティがあったとします。
手数料を計算するという振る舞いは通常業務ごとにロジックが
異なるでしょう。
手数料を計算するという振る舞いが最も強く結びついているのは
どのオブジェクトでしょうか。
それは業務(ユースケース)でしょう。
業務ごとにロジックが異なるのを考えても明らかです。
ユースケース固有のロジックはサービス層に置くほうがのが自然です
保守性があがるとおもいます。
永続化のロジックについても考えてみましょう。
例えば、従業員番号で従業員を検索するというロジックを
考えてみましょう。
このロジックが従業員エンティティに存在するのは明らかに変です。
このロジックを呼び出すのは、従業員オブジェクトを手に入れる前の話だからです。
エンティティそのものを更新したり削除したりするロジックは
どうでしょうか。
これはエンティティにあっても良いのかもしれません。
しかし、同一エンティティに対する検索と更新のロジックが
別々の場所に存在すると保守性が悪くなります。
永続化ロジックをエンティティにではなく、永続化層に置く
のは自然なことです。ほうが保守性が高くなると思います。
このように考えていくと、業務ロジックを
サービス層、永続化層におくことは、狭い意味でのオブジェクト指向とは
異なりますが、振る舞いは最も結びつきの強いオブジェクトに置いたほうが
分かりやすく保守性が高まるという点では現実的だと思います。
