ドメインモデルあれこれ
digitalmorning.netさんの「サービス」と「処理」というエントリのコメント欄に
■ ドメインにビジネスロジックがある場合の問題点
1.メソッドがありすぎて、ビジネスロジックが分かりにくい。
2.疎結合性が満たされているか疑問。
3.完璧に設計しないともろい(遊びが少ない)
4.Generation Gap（自動生成が難しい)
5.技術者が育ってない。
とありまして。これについて思ったことをつらつらと。
1.メソッドがありすぎて、ビジネスロジックが分かりにくい。
メソッドがありすぎるのは、ひとつのクラスに必要以上に多くのデータやメソッド持たせているのが原因であってドメインモデルの問題ではないと思うな。解決方法としては、メソッド多いなーと思ったタイミングで適宜クラス抽出をしてやればＯＫかと。
また、あるひとつ画面でしか使われないユーティリティ的なメソッドを「データと振る舞いを同じ場所に」という名目のもとドメインオブジェクトに追加していく、なんてのもメソッドありすぎの原因になったりします。
「問題領域(ドメイン)」のクラスに「画面(ビュー)」のロジックが入り込む、なんてのはクラス凝集性の低下につながるので避けた方がいいよ、そういう場合はデータと振る舞いは一緒にしなくてもいいんだよ*1、とはラーマン師匠のお言葉。
「データのパーシステンスロジック」をドメインクラスから分離する、なんてのも凝集性を上げるのに一役買います。以前JavaWorldの記事で読んだ「データとパーシステンスロジックを分ける理由は、データを振る舞いを分けるのが今のムーブメントだから」っていうのは間違いだと思うよ。
2.疎結合性が満たされているか疑問。
ドメインモデルだからという理由で疎結合性を阻害するってことは無いと思うなぁ。むしろ構造化設計の方が結合度が高いことが多い印象。
「全モジュールが全テーブルにスタンプ結合」してる構造化設計を、「各テーブルにスタンプ結合したモジュール群(主にドメインロジック)」と「そのモジュール群にデータ結合するモジュール群(主にアプリケーションロジック)」へと変更することにより疎結合性を高めることが可能なのがオブジェクト指向(=ドメインモデル)のメリットなわけで*2。極端な話だけど。
4.自動生成が難しい
MDAとかよくわからんけど懐疑派なのでDDI。
5.技術者が育ってない。
ですね。
なんてｵﾓﾀ。
