S_a_k_Uの日記みたいなDB

~サクゥーと呼ばないで~

ドメインモデルという言葉の使い方に自信がない

この辺りでひがさんの認識が読める???


ひがやすを blog > [goya]レイヤとモデル
http://d.hatena.ne.jp/higayasuo/20050817#1124260949
Ouobpo > ドメインモデルに対する日米の温度差
http://ameblo.jp/ouobpo/entry-10036477015.html
マイコミジャーナル > Modeling Forum 2006 - Seasarひがやすを氏の提案するページ駆動開発とは?
http://journal.mycom.co.jp/articles/2006/09/14/mdf/menu.html


モデリングのパターンとして、
・Transaction Scriptパターン
・Domain Modelパターン
ってのがあって、Transaction Scriptパターンについて、ひがさんのブログを引用した、

私は、エンティティに振る舞いが割り振られているのが良いオブジェクト指向ではなく、より現実のモデルをうまく写像しているのが良いモデルだと思っています。[...]
 私たちが業務で行っているようなことは、伝票とアクティビティを素直にエンティティとアクティビティ用のインターフェースにマッピングするのがいちばん簡単で変更にも強くなると思います。また本質的なことではありませんがDIと非常に相性が良い。
 エンティティに振る舞いを与えようとするドメインモデルは、現実との乖離があるだけでなく、結構DIと相性が悪いと思います。

この辺りの記述は共感できる。

好みというか、ちゃんとモデリングできてねぇってことかもしれんけど、従業員クラスには、//給与を計算する()メソッドは持ちたくねぇな。
就業規則(会社との契約)クラスに、//給与を計算する(従業員)って感じはありだけど。
それよりも給与計算クラスを見出して、//給与を計算する(就業規則, 従業員)ってのが好き。
給与計算クラスが就業規則クラスへの関連をも持ってて、//給与を計算する(従業員)でもいい。
それで、例えば従業員オブジェクトor就業規則オブジェクトに、給与計算オブジェクトをDIで突っ込んで、委譲で従業員あるいは就業規則に給与を計算するメソッドを実装する、というような設計のシナリオは想像できる。
実際の給与計算は、勤務実績だったり、人事評価だったりするような要素もあるだろうし。
ということで、
・DIとの相性の話
・いままでも分析レベルでアクティビティをクラスとして見出してた
・そもそも現実でも自分で給与計算せんしw
ということもあって、違和感ない感じ。
ある意味好みのような気するし(爆


そんで、ひがさんはレイヤパターンにより依存関係を維持することについて、言及しているのでそこもいい感じ。


で、ドメインモデルの話に戻してw
ビジネスロジックドメインモデルを別々に捉えているから違和感がある???
Domain Modelパターンとしての「ドメインモデル」では違和感があるけど、Transaction Scriptパターンとしての狭義の「ドメインモデル」だと違和感がないと読めたけどどうだろう?
上記の共感する部分とTransaction Scriptパターンという前提があれば、あんまり違和感ないけど、ドメインモデルって言葉だと誤解を招くのかな?というのも判るような気がする。