0

この記事を見つけるまで、私はロール固有のリポジ​​トリを知りませんでした：

太陽の下ですべてのメソッドを公開するキャッチオールリポジトリの代わりに、役割ベースのインターフェイスにインターフェイス分離の原則を適用し、1つのクラスに必要なものだけを公開するインターフェイスを定義することもできます。 

public interface IProductRepositoryForNewOrder
{
    Product[] FindDiscontinuedProducts();
}

単一のリポジトリ実装はすべての製品リポジトリインターフェイスを実装しますが、必要な単一のメソッドのみが公開され、呼び出し元によって使用されます。

a）2つの違いは、特定のリポジトリではアグリゲートルートごとに1つの特定のコントラクトがあり、ロール固有のリポジ​​トリではアグリゲートルートごとに複数のコントラクトを持つことができます。これらのコントラクトはそれぞれ、アグリゲートで動作する特定の呼び出し元のニーズに合わせて調整されます。根？

b）あなたの意見では、2つのパターンのそれぞれの長所と短所は何ですか？

ありがとうございました

アップデート：

昨日、私はあなたの答えの1つを見つけました。本質的に、役割固有のリポジ​​トリパターンを使用する必要があると主張しています。

「もう1つのオプションは、OrdersSelectorServiceの代わりにラムダを使用することです。ラムダがご使用の言語で使用できない場合は、インターフェースである必要があります。OrderRepositoryを渡すことの利点は、不必要な結合を減らすことを目的としたインターフェース分離の原則に基づいています。 Customerの動作に、OrderRepositoryのすべてのメソッドが必要になる可能性は低く、代わりに特定の関数が必要になるため、明示的にしてください。」

上記の抜粋で、役割固有のリポジ​​トリパターンの使用を推奨しているのはなぜですか。ただし、ここでは、特別な状況でのみ使用することを推奨しているようです。他のトピックの例は特別な状況です（ただし、あなたが自分自身と矛盾していると言っているわけではありません。役割固有のパターンを使用するかどうかに関して、2つの例がどのように異なるかはわかりません） ？

4

2 に答える 2

2

a）はい。これは、実際のインターフェース分離の原則です。役割/ユースケースを明示的にする。利点は、依存関係を減らして「クリーンアップ」することです。

b）私にとって、役割固有のアプローチの主な欠点は、インターフェイスの急増と、その結果としての配線や参照などの増加です。ただし、この欠点は、原則の欠陥によるものではなく、それ以上のものと見なすことができます。プログラミング言語で。たとえばF＃などの関数型言語では、インターフェイスではなく関数が急増しているため、インターフェイスの分離がデフォルトのアプローチです。ある意味で、関数は「より鋭い」ツールです。

非役割固有のアプローチの長所は、データアクセスコントラクトを定義する単一の言語要素、インターフェイス、またはクラスと見なすことができることです。場合によっては、技術的な観点からアーキテクチャを評価することが重要です。

于 2013-01-09T06:29:34.767 に答える
2

私はすべてSOLIDコードに賛成ですが、特にDDDコンテキストでは、インターフェイス分離の原則には限界があります。

[ニトピッカーモード]

手紙にISPを適用する場合、記事からリポジトリに関するステートメントをほぼ取り出して、少し変更して次のように言うことができます。

ドメインエンティティを使用するクラスは、その内部のすべてのメソッドを使用することはめったにありません。

したがって、ドメインエンティティごとに、エンティティのクライアントと同じ数のインターフェイスを作成し、各インターフェイスのクライアントに関連するメソッドのみを作成して、エンティティにこれらのインターフェイスを実装させる必要があります。

もちろん、これはばかげているし、誰もそれをすることはありません。でもねえ、ISPは普遍的なOOの概念であるはずですよね？

[/ニトピッカーモード]

ここで、ISPが元々の理由を振り返ると、ISPはファットなインターフェース、つまりまとまりのないインターフェースと戦うことになっています。しかし、リポジトリ自体はまとまりがありませんか？それは基本的なアトミックDDDビルディングブロックではありませんか？数十のミニクエリオブジェクトに分割する価値がありますか？その上、私たちのドメインの各クラスは、ユビキタス言語と整合していると想定されていませんか？これは、、、..などのインターフェイスにはほとんど当てはまりませProductRepoInterfaceForClient1ん。ProductRepoInterfaceForClient2ProductRepoInterfaceForClient3

誤解しないでください。ISPは、特にインターフェイスのコントラクトが本来よりもはるかに異質であるかどうかを検出する方法として、依然として役立ちます。ボブおじさんのISPに関する元の論文には、その良い例があります。「インターフェイスの汚染」の段落とATMの例を参照してください。

しかし、妥当なレベルの結束が達成されたら、特に基本的なDDDの原則と矛盾する場合、または維持するのが悪夢となる何百ものインターフェイスでコードベースを氾濫させる場合は、ISPを盲目的に適用しないでください。

于 2013-01-09T13:17:28.543 に答える