クラスOrder（ユーザーに関連）があり、プロパティーにはstateがあるとします。私は同じ時間に複数の確認された注文があるのを防ぐため、注文を確認する前に、確認済みのものがあるかどうかを確認する必要があります。リポジトリにドメインオブジェクトまたはリポジトリを注入すると、ビジネスロジックを意識する必要がありますか？
私は2つのアプローチ（私の知っている）を作ることができます。
OrderRepositoryを競合の検索機能changeStateはそれを変更する前に注文を確認し、何も見つからなかった場合にのみ、それを可能にしている - ここでの問題は、リポジトリです状態の変化の論理を知っている。
OrderRespositoryはOrderに注入され、Orderは競合をチェックするために、そのリポジトリを使用する機能changeStateを持っている - ここでの問題は、ドメインオブジェクトを永続化について知っています。
正しい方法はありますか？
リポジトリはドメイン不変量を管理していません。集約があります。不変量をチェックするために必要な情報がアグリゲートにない場合は、アグリゲートデザインに疑問を呈し、新しいものを考え出してみてください。
ドメインサービスを使用することもできます。弱い選択肢として、ドメイン不変条件を単純なユースケースの前提条件に下げて、アプリケーションサービス/コマンドハンドラでチェックすることもできます。後者の2つのオプションは、ドメインエンティティがそのルールに関して常に一貫した状態になることを強く保証するものではないことに注意してください。
これについて考えるもう1つの方法は、リポジトリの責任という観点からのものです。最後に、リポジトリは、オブジェクトのコレクション（あなたの場合はオーダー）をどう扱うかを表現する抽象です。
したがって、コレクションがリポジトリ層で表現されるための整合性と正しい状態の規則を維持することは理にかなっています。リポジトリをエンティティに注入することは、おそらく、何かが正しくモデル化されていないというコードの匂いです。私はあなたの最初のバージョンに行くつもりですが、あなたの状態の変化について具体的にする必要はないかもしれませんが、単にそれらのルールをsave()メソッドに埋め込むだけです。同時に他のものが確認されていない場合は、変更をオーダーに保存することができます。
私はこれに本当に同意しません。リポジトリは、ビジネスルールを見つけることが期待される場所ではありません。 – guillaume31
あなたは純粋主義の立場から正しいでしょう。しかし、私はこのようなこと（チェックとテン保存）のために並行処理の問題が多すぎて、純粋な状態に保たれていませんでした。システムがメッセージ駆動型でない限り、私はこの特定のケースではもう少し実用的だろう。 – hasumedic
私は分かりません。コードの管理者であっても、競合する注文ルールが実装されている場所は、「OrderRepository」とは思わないでしょう。それは、最小の驚きの原則に反する。これは非常に実用的です。 – guillaume31
エンティティがリポジトリにアクセスすることは可能ですか？（http://stackoverflow.com/questions/827670/is-it-ok-for-entities-to-access-repositories） – guillaume31
Nope、been 2番目のアプローチが悪いことを知りましたが、私はそれを適切に処理する方法をまだ分かりません。 – kuba
あなたのQのタイトルはあなたが本当に探しているものを反映していません - あなたはそれを変更する必要があります。 – guillaume31