ビジネス・ロジックの置き所

いわゆる「ビジネス・ロジック」と呼ばれているものがある. ドメイン知識の一部だけれど, 「処理」的なもの, 複数のドメイン・クラスにまたがる何かを指している.



grails ではビジネス・ロジックは service として実装しなさい, というのが基本だ. domain class には書かない. そして service は controller が呼び出すもので, domain class が呼び出すものではない. これは grails に限らず, 最近の実装法はこの方向にある. domain class という名前ではあるけれど, 実態は DTO (Data Transfer Object) に過ぎない. そして DAO (Data Access Object) を通してアクセスする. しかし, そもそも DTO とか DAO とかいう名前, 存在そのものはオブジェクト指向としてどうなのよ? 気持ち悪いなぁ.



元々オブジェクトは現実世界の何かに関する知識を表すものだった. ドメイン・クラスとか概念オブジェクトとかは, その中でも問題ドメインに関する知識を表すオブジェクトだ. でも DTO とか DAO とかって解決領域に関するものでしょう? 実装依り過ぎる. それは裏に隠れている (別のドメインである) べきなんじゃないの?, というのが僕の, 実行可能知識の立場.



例えばあるメーカが小売店に対して報奨金を出している. 前期の売上額の範囲に応じて, 報奨金の割合が変わるとする. もちろんこの報奨金のルールの内容自体は不安定なもの (人間の恣意によって変わりやすい) ものだから, 「ルール」として抽出してよい (するべき). でも, このルールによって計算される報奨金というものがあると言うことは「ドメイン・クラス」の中に書かれているべき.



むろん, 昨今の実装上の問題として, 永続化層がオブジェクトをそのまま保存できない場合が多いので, この「ルール」がいつ起動されるべきか難しいわけだが...



続きはまた書く.