http://q.hatena.ne.jp/1306065945の質問続き。

あくまでも、私見です。

オブジェクト指向な設計が、従来の手法と違うメリットというのは、機能をベースにして設計しないことで、予期せぬ仕様変更に対しても、コードの変更が局所化される（あちこち変更しなくても済む）ことだと思ってます。

1.S2JDBCを使ってDBアクセスを行うクラスを○○Serviceと呼ぶのはなぜか。

DAO に対する、アンチテーゼの意味が込められているのかな、という気がしてます。

DAO の守備範囲は、アクセス方法を隠ぺいすることだと思うのですが、実際には、ひとつのテーブルをアクセスする SQL を隠ぺいするだけのクラスが、大量に作られるだけで、テーブルの構成が変更されるような仕様変更に弱い、ということが往々にしてあります。

単純にアクセスの実装を隠ぺいするだけではなく、「サービス」を提供する実装にしてね、という意味が込められているのかな、と、勝手に思ってます。

ビジネスロジックはどこに書くべきか。

「ビジネスロジックとは何か」という明確な定義が無いので、この問いに対する答えは（今のところ）無いのだと思ってます。

最近の流行りだと、データの整合性を保証するのがビジネスロジックで、それを隠ぺいするのは MVC でいう "Model" だ、というのがしっくりきます。

DB の正規化によって、意味のあるデータの一群が複数の DB に分かれている場合、ひとつのトランザクションで不整合が起きないように保証するのが "Model" の役割だと。

ActionForm は、問い合わせのデータの集合体 (位置付け的には、DTO) なので、ここに書くのは不適切だと思います。

Entity は、seasar では、ひとつのテーブルの写しだと思うので、単純な構成では、ここにビジネスロジックが書かれることもあると思いますが、「ロジック」が実装に左右されるものでは無い、と考えると、それを表現する「層」があっても良いのかな、と。

仮にServiceにビジネスロジックを書く場合、ActionFormのリクエストパラメーターの値をDtoに詰めて

　Serviceクラスに引渡し、Serviceクラスのビジネスロジックで導出した値をDtoに詰めて返す、というような処理は一般的か。

そういう実装は多いと思います。

ただ、ひとつのリクエストで、Service が要求する INPUT が満たせるかどうかは、UI によるでしょうし、Service の応答についても、同じことが言えると思います。

ActionForm をベースに考えると、UI の変更が、DTO に、即、影響を与えるでしょうし、その DTO をベースに Service を設計すると、UI の変更が、そのまま Service の変更につながるので、正しい方法なのか、と言われると、そうじゃない気がします。