私はアプリケーションのリファクタリングの過程にあり、特定のロジックがどこに収まるべきかを理解しようとしています。たとえば、登録プロセス中に、メール アドレスに基づいてユーザーが存在するかどうかを確認する必要があります。これにはユーザーがデータベースに存在するかどうかをテストする必要があるため、データベース内に存在することによってその存在が決定されるため、このロジックをモデルに結び付けるべきではないように思われます。
ただし、メールなどでユーザーを取得するためのメソッドをリポジトリに用意します。これは、ユーザーが存在する場合の取得に関する部分を処理します。ユース ケースの観点からは、登録はユース ケース シナリオのように思われます。したがって、リポジトリ メソッドを呼び出して、返されたユーザー エンティティがnull かどうか。
DDDに関して、私はこのアプローチで正しい軌道に乗っていますか? 私はこのシナリオを間違った方法で見ていますか?もしそうなら、これについての私の考えをどのように修正すればよいですか?
このリンクは可能な解決策として提供されました。ユーザーの電子メールが既に存在しないことを確認する場所は? . それは役に立ちますが、問題のループを閉じるようには見えません。この記事に欠けているように思われる点は、CreateUserService オブジェクトが他の関連パラメーターと共にメソッドに注入される集約ルート上のアプリケーション サービスまたはメソッドである CreateUserService の呼び出しを担当するのは誰でしょうか?
答えがアプリケーション サービスである場合、ドメイン サービスをドメイン レイヤーから取り出すことでカプセル化が失われているように見えます。一方、逆の場合は、リポジトリをドメイン サービスに挿入する必要があります。これらの 2 つのオプションのうち、どちらが望ましく、DDD に沿っているでしょうか?