リポジトリ層にドメインロジックを含めないようにします。

Question

現在のアプリケーションでは、アーカイブ ("isArchived" ) され、同時に 1 か月以上非アクティブなユーザーを返す API GET ルート「/inactive-users」を作成する必要があります。 old ("lastVisitedDate" フィールドは new Date() - 1 month よりも古い必要があります)。

階層化アーキテクチャ (コントローラー/サービス/リポジトリ) が使用されており、ドメイン モデルが貧弱です。この場合はどうすればよいですか?

考えられるアプローチは 2 つあるようです。

1 - ユーザーを取得する汎用リポジトリ メソッドを作成し、必要なユーザー フィールドを渡します。

リーリー

2 - 非アクティブなユーザーを取得するためのリポジトリ メソッドを正確に作成します。メソッドはどのフィールドをリクエストする必要があるかを認識します。

リーリー

どちらの方法が良いですか? 最初の方法は、この場合リポジトリが「非アクティブな」ユーザーのドメイン理解について何も知らないため、私にとっては良いように思えます。しかし同時に、そのような事後対応型のアプローチを構築するのは非常に難しい場合があります。

2 番目の方法は構築が簡単ですが、同時に、ある程度の「ビジネス」ロジックを理解しており、非アクティブなユーザーが "isArchived" が false## に等しいユーザーであることを認識しています。 ＃。また、このリポジトリ メソッドは、何日間使用する必要があるかを認識します。

この場合、どのオプションを選択する必要がありますか?それとも、これを構築する他の方法があるでしょうか?

Answer 1

この問題を切り分ける正しい方法は、リポジトリがリポジトリ内のデータ要素についてのみ認識していることです。これは、リポジトリに複数のエントリ ポイントを持つことができないという意味ではなく、すべて同じ「テーブル」にアクセスする多くの異なるクエリが存在する可能性があります。

これは、最初のアプローチのような完全な QBE が必要という意味ではありません。シンプルにしてください。データベース レベルをカプセル化するクエリがありますが、それでも必要なものは必要です。

この場合、isArchived パラメーターと lastVisitedDate パラメーターを渡す署名が必要です。 QueryUsersByStatusAndLastVisited のようなもの。このように、リポジトリはデータの取得に関係するすべてのビットを処理しますが、なぜそれらが取得されるのかについてのロジックはありません。すべてのスマート ビットがサービス層にカプセル化されているため、これは「ダム」になります。