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

[[E-MAIL ADDRESS DELETED]]

片岡です。

Serviceに変えた意図は十分理解できました。丁寧な説明ありがとう
ございます。

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

おっしゃるとおりと思います。

>このServiceの使い方は、Domain Driven DesignのServicesパターン
>にあわせています。
>http://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap2.

ただ、内容は難しいですね。ブログ側にも話を展開されてますが、そちら
については、おいおい勉強していきたいと思います。



>>  
>>     * [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のサービスはドメインモデルの中にあるサービス的なものを指している。


ご迷惑をおかけしますが、よろしくお願いします。
_______________________________________________
Seasar-user mailing list
[E-MAIL ADDRESS DELETED]
https://ml.seasar.org/mailman/listinfo/seasar-user