ZendFrameworkとDoctrine2を統合していて、 Serviceレイヤーを発見しています。
今、私は2つのアーキテクチャが可能であることを理解しています（私は間違っていますか？）：
それぞれの長所/短所は何ですか？
ドメインロジックをモデルの外部に配置してOOPを失うのは奇妙に思えるので、なぜサービスレイヤーを使用するのかわかりません。
サービスレイヤーがモデルの外部にあると思われる理由は何ですか？そうではありません。実際、これは、エンティティ、リポジトリなどとともに、モデルの中心的な部分です。
Doctine2を使用している場合は、サービスレイヤーが必要になります。理由の1つは、エンティティにEntityManagerについて知られたくないということです（テストのしやすさを損なう）。もう1つは、コントローラーがEMを駆動することを望まないことです（永続性について知るのはコントローラーの仕事ではありません）。
私は通常、サービスレイヤーがモデルへのコントローラーのインターフェイスであるアーキテクチャを使用します。サービス層は、エンティティを操作する関数を公開します（エンティティをパラメーターとして受け取るか、返すか、またはその両方）。エンティティの永続性は、サービスレイヤーによって隠されています。サービスクラスはEMとリポジトリ自体を駆動するか、コントローラーが存在することを決して知らない他のコードにそれを委任します。
そのため、サービスレイヤーは、コントローラーがビジネスデータを操作するために使用できるAPIを提供します。