賢いデータは必要なのかのコメントから
て書いてあるけど、ほんとうにそうなのかな。別にデータと振舞の分離したからって「Transaction Script」パターンになるって事はないと思うんだけど。
というか、「Transaction Script」パターンは
ドメインロジックとSQLを参考にして書いてるんだけど、ここの「Transaction Script」パターンはひどすぎる。
百害あって一理なしです。別にデータと振舞の分離したからってこんなひどいことにはならないよ。
SQL内にロジック(Logic in SQL)パターンを使う事だって出来るんだし。
しかし、じぶんの感覚からするとここの例でのドメインモデル(Domain Model)パターンはなんかやな感じがする。
だって割引の適用なんてホットスポット中のホットスポットですよ。それをCustomerクラスに埋め込むなんて信じられません。割引の種類なんてあとからあとから増えていくにきまってます。そのたびにCustomerクラスにメソッドを追加するのでしょうか、細かい変更(たとえばタリスカーを5000ドル以上から2500ドル以上に変更)なんてでしょっちゅうでしょうがそのたびにCustomerクラスに手を加えなきゃいけないんですか?
自分ならDiscountManagerとか作ってそっちに処理をまわしてしまうけどな。
yusukeさんのおっしゃるデータと振舞の分離は、マーチン・ファウラーの言うところの「Transaction Script」パターン
て書いてあるけど、ほんとうにそうなのかな。別にデータと振舞の分離したからって「Transaction Script」パターンになるって事はないと思うんだけど。
というか、「Transaction Script」パターンは
ドメインロジックとSQLを参考にして書いてるんだけど、ここの「Transaction Script」パターンはひどすぎる。
百害あって一理なしです。別にデータと振舞の分離したからってこんなひどいことにはならないよ。
SQL内にロジック(Logic in SQL)パターンを使う事だって出来るんだし。
しかし、じぶんの感覚からするとここの例でのドメインモデル(Domain Model)パターンはなんかやな感じがする。
だって割引の適用なんてホットスポット中のホットスポットですよ。それをCustomerクラスに埋め込むなんて信じられません。割引の種類なんてあとからあとから増えていくにきまってます。そのたびにCustomerクラスにメソッドを追加するのでしょうか、細かい変更(たとえばタリスカーを5000ドル以上から2500ドル以上に変更)なんてでしょっちゅうでしょうがそのたびにCustomerクラスに手を加えなきゃいけないんですか?
自分ならDiscountManagerとか作ってそっちに処理をまわしてしまうけどな。