Open6
ビジネスロジックやらクリーンアーキテクチャやら
nkmryu実装時に同時に考えなければならない事柄を減らすこと
そうした状態を作るために有効な手段の一つとしてLayered Architectureがあるわけです。
決してLayerをきれいに分割する事自体が目的ではありません。
nkmryuアプリケーションをプレゼンテーション・ビジネスロジック・データアクセスの 3 つに分けたとき、「プレゼンテーションでもデータアクセスでもない部分がビジネスロジック」
nkmryuRails のようなフレームワークであれば、ここまでで書いてきたパターンのうち、
Controller に全部書く
2-2. エンタープライズビジネスルールだけを Model に書く
3. Service と Model にビジネスロジックを分けて書くのどれかがいいのではないかと思います。
この中でどれを採用すべきかは状況によって変わると思います。
上ほど初期実装・学習コストで有利、下ほどメンテナンス性・テスタビリティで有利です。
Service を使う前提の Spring のようなフレームワークの場合
Spring のようなフレームワークの場合、
- Service にビジネスロジックを全部書く
- Service と Model にビジネスロジックを分けて書く
のどちらかになります。これはいわゆる**「トランザクションスクリプト」と「ドメインモデル」のどちらを採用するかという議論と同じ話**です。
nkmryuウィキペディアの Model_View_Controller のページにも、
MVC（Model View Controller モデル・ビュー・コントローラ）は、ユーザーインタフェースをもつアプリケーションソフトウェアを実装するためのデザインパターンである。
と書かれています。
実は、MVC、MVP、MVVM といったものは、全てプレゼンテーション層のアーキテクチャなのです。