サービス/アプリケーション レイヤーは、Larman が GRASP コントローラーとして説明しているのと同じものであり、GUI レイヤーを超えてドメイン レイヤーにデリゲートする最初のオブジェクトであり、別の GUI から再利用できるはずだと思います。
サービス (Evans) 層はアプリケーション (Fowler) 層と同じです。これは、Fowler 自身が「Anemic Domain Model」に関する「bliki」でそう言っているためです: http://martinfowler.com/bliki/AnemicDomainModel.html
引用: 「アプリケーション層 [サービス層の彼の名前]: ソフトウェアが実行することになっているジョブを定義し、表現力のあるドメイン オブジェクトに問題を解決するように指示します。この層が担当するタスクは、ビジネスにとって意味があるか、相互作用に必要です。他のシステムのアプリケーション層. この層は薄く保たれています. ビジネスルールや知識は含まれていません. タスクを調整し、次の層のドメインオブジェクトのコラボレーションに作業を委任するだけです. ビジネス状況を反映した状態を持たない.ただし、ユーザーまたはプログラムのタスクの進行状況を反映する状態を持つことができます。」
ここで、上記の説明を検討し (ユース ケースからサービス層メソッドを特定することに関して、ファウラーの PEAA ブックも参照してください)、サービス層が「ユーザー インターフェイス」の後の最初の層であることを示すファウラーのサービス層の説明の図も検討してください。この URL: http://martinfowler.com/eaaCatalog/serviceLayer.html
ここで、上記のサービス/アプリケーション層の説明を GRASP コントローラーに関する Larman の言葉の一部と比較してください (彼のベストセラー OOAD 書籍「Aplying UML and patterns」の第 3 版、302 ～ 306 歳):「...最初のオブジェクトシステム操作を受け取り、調整 (「制御」) する UI レイヤーを超えて..." "... システム イベントが発生するユース ケース シナリオを表す..." "... 通常、コントローラーは他のオブジェクトは、実行する必要がある作業です。アクティビティを調整または制御します。それ自体は多くの作業を行いません...."
Larman の GRASP Controller レイヤーは、Evans/Fowler の Application/Service レイヤーと同じだと思います。他の人は同意しませんか？次に、これらの概念の大きな違いと、Service/Application クラスの代わりに Controller クラスの例を説明してください。
モデル ドメイン オブジェクトの作成は、他のサービス/アプリケーション レイヤーではなく、コントローラーの責任であると言う人もいるため、私の質問が生まれました。しかし、サービス層クラスの例とコントローラークラスの違いを教えていただけますか?