Service指向とトランザクションスクリプト
業務システムにOOはほとんど必要ないと考えている断然トランザクションスクリプト派の
わたしですがｗ、下記の説明をみても従来のトランザクションスクリプトとの違いがそんなにない気がする。
DDDのServiceパターンはエンティティとして扱えないものだけを
どのように一貫して抽出するのかというのがポイントになりそうだけど、
どの時点で扱えないと判断するのかが明確じゃないように思うので、抽出基準が
きちんと定まらず使いにくいんじゃないすかね。
というわけで、おいらは過去から一貫して、トランザクションスクリプト派で、
かつレイヤ的には
- Pageモデルを使うならば、Page（副次的にActionが入る余地あり）＋Service＋Dao
- Actionモデルならば、Action＋Service+Dao
です。
3つっていうのがわかりいいし、プレゼンテーション/ビジネスロジック/データアクセスが
きちんとわかりやすい形式で分割されている。これがベストだと思う。
足し引きはあるけども、常にスタート地点はここから開始。
Serviceを分けておくことでトランザクション境界の起動タイミングも見えやすいし、
Viewから切り離した実際のServiceはサービス指向とも言える。
ワークフローなんかもかませやすいカタチのミニマムなんじゃないかなあとも考えます。
ひがさんはトランザクションスクリプトでユースケースごとに分解されるから
重複したロジックが出るのが弱点って言ってるけど、ある程度の重複は許容するのが自分の考え。
DRYを徹底するのが仕事ではなくて、案件完遂が仕事なので許容してもいいんじゃないかなあ。
ただし共通Serviceみたいなのは必ず必要で、それがどれだけ最初に抽出できるかが
ポイントで（ここが腕の見せ所な気がする）、抽出できさえすれば
残りはServiceにServiceをDIしてdelegateすればそれで事足りると思ってます。
最近ではシステム基盤フレームワークみたいな考え方が浸透してきているので、
毎回共通Service出すことも少なくなってきてますしね。
