OOPでサービスオブジェクトは必要ですか？
私は長い間AngularJを使用しています。私と私のチームは、インターンが$httpサービスを使用するUsersのようなリモートリソースを取得するためにサービスを多用しているため、基本的に、各エンティティに対して、そのエンティティをフェッチ/保存するサービスがあります。
エンティティ自体がそれを実行でき、サービスが完全に削除されるべきでない理由を考えていました。その方向に進んでいるかどうかはわかりませんが、他人の意見を知る必要があります。
「サービス」の広範な使用は悪いOOPを示します。ただし、開発の性質上、場合によっては、サービスのようなクラスが避けられないことがあります。
ユーザーエンティティは、自分自身を格納または取得する責任を負いません。自身を格納することはOOPに違反しませんが、懸念の分離や単一責任の原則など、多くの優れたアーキテクチャ上の慣行に違反します。オブジェクトがそれ自体を格納および取得できるようにすると、アプリケーションがveryもろくなり、保守が難しくなります。
ストレージと検索サービスが必要になります。ただし、単にサービスにラベルを付けるだけでは、やや怠惰な作業です。 OOPは動詞の名詞についてです;このサービスをもう少しOOPにしましょう...
CRUDのみを担当するオブジェクトはリポジトリと呼ばれます。 notにはCRUDメソッド以外のものが含まれている必要があります。 GiveUserPermissionのようなメソッドを持つリポジトリが見つかった場合、リポジトリパターンに違反していますが、それはそこに属していません。 UserクラスまたはUserおよびPermissionのメディエータークラスに属しています。各エンティティには独自のリポジトリが必要です。リポジトリーは、複数のエンティティーに対して責任があってはなりません。そして、それはテーブルごとではなく、エンティティごとです。
リポジトリがデータベースからデータを取得するか、httpレストコールを取得するかは関係ありません。アプリケーションの残りの部分は、この詳細に無知でなければなりません。
DDDでは、エンティティはリポジトリから自分自身をロードしません。これは、アプリケーションサービスの責任です。これは、エンティティを純粋な状態に保つためにこの方法で行われ、副作用はありません。このようにして、少なくとも2つの利点を得ることができます。1）それらはよりテスト可能であり、2）コマンド操作は再試行可能です（これは楽観的ロックと組み合わせると、スケーラビリティの大きなステップになります）。
ただし、フロントエンドは、Aggregate戦術的なデザインパターンの典型的な候補ではありません（AngularJを、nodejsバックエンドアプリケーションではなくクライアントアプリケーションとして使用する場合）。したがって、セキュリティ上の理由から、おそらくアプリケーションのサーバー側でビジネスルールを適用します。これは、フロントエンドがコマンドをバックエンドアプリケーションに送信するだけで、ビジネスルールに従って状態を変更するアグリゲートがあり、適用する必要のあるビジネスルールがないことを意味します。最良の場合、より良いUXのためにいくつかのビジネスルールが複製されています。
結論として、フロントエンドにはDDDエンティティ/集約がないため、任意のロードパターンを使用できます。