私は最初のDDDアプリケーションをモデリングしていますが、この疑問に悩まされていました...
私のアプリケーション層とインフラストラクチャ層には、永続化する必要のある詳細がいくつかありますが、これらはドメイン固有ではないため、リポジトリという名前を付けるのは好きではありません。誰かが私がそれに名前を付ける方法を理解するのを手伝ってくれる?
ありがとう。
私は最初のDDDアプリケーションをモデリングしていますが、この疑問に悩まされていました...
私のアプリケーション層とインフラストラクチャ層には、永続化する必要のある詳細がいくつかありますが、これらはドメイン固有ではないため、リポジトリという名前を付けるのは好きではありません。誰かが私がそれに名前を付ける方法を理解するのを手伝ってくれる?
ありがとう。
DDDとリポジトリパターン(RP)は別物であり、DDDがRPを利用するのはたまたまです。これは、永続性に関連するすべてをリポジトリにラップできることを意味します。それらはドメインリポジトリではありません。おそらくあなたの場合、PaymentGatewaysRepositoryまたはそのようなsmthがあります。
重要なのは、永続アクセスの詳細をクラスにラップして、アプリの残りの部分がストレージを気にしないようにする場合、そのクラスにどのように名前を付けても、リポジトリパターンを使用しているということです。
もう少し詳しく説明する必要があります...なぜモデル化されないのですか?それは構成設定だけですか、モデルの範囲外のものですか?ログなどのように?いくつかの名前が思い浮かびます:シリアル化、構成、設定など。
あなたのコメントを考慮すると、構成設定は実際にはドメインモデルに直交していますが、支払いゲートウェイの設定はモデルの外にある場合とない場合があります。Idは、作成しているアプリケーションの種類によって異なります。支払い処理業者を作成している場合、それは正真正銘の「あなたの」ドメインモデルのメンバーであると私は信じています:-)モデルで一般的な構成をモデル化することもできます...ユーザーが独自のオーバーライド設定を持っていると想像してください。 。構成「モデル」は、ドメインモデルを弱く参照する可能性があります。
これらの詳細を別のドメインで完全にモデル化することもできます...独自の永続性を備えた再利用可能なドメインモデルであり、アドオンとしてさまざまなドメインで使用できます...