サービス層の設計
PHPでMVC Webサイトを開発しています。初めて、サービスレイヤーを実装したいと思います。いくつかの設計上の考慮事項があり、アドバイスを求めたいと思います。バックエンドは決して大規模なエンタープライズシステムではないので、サービスレイヤーの利点を活用しながら、物事を比較的シンプルに保つことを目指しています。
私のコントローラーはサービスと対話し、次にサービスはDAOと対話するという考えです。私の主な質問は、サービスをいかに細かくすべきかです。私はSOAのサービス細分度の概念に精通していますが、これを実際に実装したことはありません。たとえば、ユーザー登録を処理するには、RegistrationServiceクラスが必要ですか、それともUserServiceメソッドと他のユーザー関連サービスを含むregisterが必要ですか？前者のアプローチは、小規模または細粒度のサービスでいっぱいのサービスレイヤーを用意することを意味しますが、それは良いことだと思います。後者はサービスの再利用を妨げ、多くのメソッドを持つ大きなクラスをもたらすようです。
代わりに、おそらく2つのアプローチを組み合わせて、サービスを確実に再利用できるようにする必要がありますか？たとえば、DAOクラスと対話するRegistrationServiceがあります。次に、UserServiceメソッドを持つregisterクラスを作成できます。このメソッドは、きめ細かいRegistrationServiceと相互作用します。このように、RegistrationServiceを簡単に再利用して、より粗いサービスを構成できます。確かに、再利用の可能性が高くなる例があります。たとえば、注文を行うには、さまざまなサービスを使用または調整する必要があります。これは、先ほど説明した「レイヤード」アプローチと呼べると思います。サービスレイヤーが混乱しないようにこれを構成できますか？
私が上記で提示したアイデアについて他の提案、推奨事項、経験、コメントがあるかどうかにかかわらず、これについてのあなたの考えを聞いてみたいと思います。前もって感謝します。
まあ、私はRegistrationServiceのほうが意図を明らかにしていると思います。
registerUser()、ConfirmRegisteration()、ResetPassword()、...など、そこにある関数を簡単に推測できます。私にとってそれらのほとんどは、一般的なRegisterionServiceクラスよりも論理的にUserServiceクラスに分類されるようです。
サービスレイヤーには、複数のエンティティを操作する関数が含まれることになっているため、UserServiceは論理的にはそのような操作に最適な場所ではない場合があります。
今日のPHPフレームワークの実装はサービスレイヤーを使用しません。すべてのデータベース計算はモデルレイヤーに保存されます（Doctrine＆Co）。挿入したい場合モデルとコントローラーの間のサービス層。「トランザクション」と考える必要があります。
この層を使用すると、データベース層（DAO）にアトミック操作のみを配置し、サービス層のトランザクション内でそれらを連鎖させることができます。 RDMが部分的なトランザクションのロールバックをサポートしている場合、これはさらに理にかなっています。
したがって、このレイヤーは、技術的な例外（データベースの主キーの例外）がビジネスの例外（注文の例外を配置できません）になるポイントになります。
ORMの考えでそれをきれいに実装する方法がわからない...