[Seasar-user:14257] Re: SAStruts 1.0.2-rc3 リリース

[Yasuo Higa]

ひがです。
> 
> 片岡です。
>  
>     * [SASTRUTS-41] - Logicを使うのやめてServiceを使うようにしました
> 
> に関して、その意図を教えてください。
> 
> diconファイルを見る限り、LogicからServiceへの単純な名称変更と
> 理解しました。なので実用上はどっちでもよい気がするし、SAStrutsの
> LOGICクラスも徐々に浸透していると思うので、ことさら今変えなくても
> よいのでは？と感じたのですが...。
> 
http://d.hatena.ne.jp/higayasuo/comment?date=20080517#c
でも突込みが入ってますね。

> 他のS2プロジェクトとの整合性なのでしょうか。それとも、それ以外の設計
> 指針の示唆や、特別なロジックなどありますでしょうか。
> 
話の流れとしては、

・最初はユースケースのビジネスロジックはActionにかこう。
複数のActionで共通的なロジックはServiceにかこう。

・次はそのServiceは一般的なServiceとは違うからLogicにしよう。

・今は、Actionにビジネスロジックを書くと肥大化しやすいということが
いくつかのフィードバックを経てわかってきたので、
Entityごとに Serviceを用意し、ビジネスロジックは
ServiceまたはEntityでかこう。
用語としては、Logicよりも一般的なServiceにあわせるよ。

ということなんですが、最後の
「用語としては、Logicよりも一般的なServiceにあわせるよ」
の部分が、いまさら変えなくてもと皆さんが思っている部分ですよね。

このServiceの使い方は、Domain Driven DesignのServicesパターン
にあわせています。
http://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap2.html#Services
ドメインで扱う概念の中には、1つの機能や処理が単体で存在していて、
もの（オブジェクト）として扱うのが不自然なものもある。
そうしたものは、サービスという形でユビキタス言語に組み込む。
サービスは基本的に状態をもたない（stateless）。

（PofEAAのService Layerパターンとは異なる概念なので注意。
Service LayerパターンはDDDのアプリケーション層に相当するものを言っているが、
DDDのサービスはドメインモデルの中にあるサービス的なものを指している。

だったら、最初からそうしろよというお叱りは、重々承知していますが、
標準的な言葉で説明できることは、標準にあわせていたほうが、
最終的にはユーザのためになると思っています。

ご迷惑をおかけしますが、よろしくお願いします。