1)
a) ACL Facadeは、 BCが必要とする他のシステム(外部システム、またはチームによって開発された別の境界コンテキスト)の機能へのアクセスのみを提供します。他のシステムが ( BCが関心を持っている) いくつかの異なる責任に分類できる機能を公開している場合、これらの責任ごとに1 つのACL Facadeを定義するか、単一のACL Facadeですべての責任を公開する必要があります (外部システムによって提供されます) 。私たちのBCニーズ？
b) a )に対する答えが、外部システムによって提供される責任ごとに 1 つの ACL Facade を定義する必要がある場合、各 ACL Facade に対して 1 つの ACL サービスも定義する必要がありますか?!
2)
a) エヴァンの本 ( pg. 366 ):
AntiCorruption Layer のパブリック インターフェイスは、通常、一連のサービスとして表示されます。このモデルでは、外部システムを単一のコンポーネントとして表現することは意味がないかもしれません。複数のサービスを使用するのが最善の場合があります。それぞれのサービスには、モデルに関して一貫した責任があります。
ACL自体はドメイン層内に存在しませんが、上記の引用によれば、ACL サービスはドメインの概念を表していませんか? もしそうなら、次のように主張できないでしょうか。
I - ACL サービスはドメイン サービスですか。
II - そのドメインの概念がACLに漏れた?
b) ACL サービスの責任は何ですか? BCと外部システム(つまり、他のBC ) との間を単に仲介するため、またはACL サービスが外部システムによって提供される責任とは異なる責任を持つことができます。そのため、ACL サービスは、外部システムによって提供される機能を使用して、独自の指定されたタスクを実行することができます。 ?
3) エヴァンの本 ( pg. 366 ):
AntiCorruption Layer のパブリック インターフェイスは、通常、一連のサービスとして表示されます。このモデルでは、外部システムを単一のコンポーネントとして表現することは意味がないかもしれません。複数のサービスを使用するのが最善の場合があります。それぞれのサービスには、モデルに関して一貫した責任があります。
著者は、外部システムを単一の責任を持つものとして表すのは意味がないかもしれないと言っていますが、代わりに、そのシステムは複数の責任を持つものとして表すことができるので、 ACL Facade + ACL サービス(および対応するAdapter ) をそれぞれに対して定義します。これらの責任？
4) ところで - ACL は、同じアプリケーション内に存在し、同じチームによって開発された2 つの境界コンテキスト間でも定義できると思いますか?
アップデート：
1)
a) あなたの理由がよくわかりません:
ファサードが同じプロジェクトによって異なる責任で使用されている場合でも、同じ境界付きコンテキストに分類される場合は、同じファサードを使用してください。外部システム API 軸に沿った技術的結束の利点は、責任軸に沿った機能結合の利点を上回ります。
I. " at " はタイプミスであり、" and "?に置き換える必要があると思います。
Ⅱ．「異なる責任は依然として同じ境界コンテキストに分類される」とは、 Facadeが単一の BCの責任のみを公開しているという事実を指していますか?
III. また、Facadeが複数の BCの責任を公開している場合、これらの外部 BCごとに1 つの Facadeを用意する必要がありますか? はいの場合、すべてのBCに対して単一の Facade を使用するよりも優先されるのはなぜですか? Facade インターフェースがめちゃくちゃになるという理由だけでしょうか?
IV. 「ファサードが同じプロジェクトで使用されている場合」とは、両方の BCが同じアプリケーションの一部である場合、単一のファサードを使用してすべての責任を公開する必要があることを意味しますか? また、別のBCが別のアプリケーションに属している場合はどうなるでしょうか。
V.
外部システム API 軸に沿った技術的結束の利点は、責任軸に沿った機能結合の利点を上回ります。
機能的結合よりも技術的結合が好まれるのはなぜですか?
b)
ファサード自体は、事実上、サービスまたはサービスのセットです。追加のサービスを定義する必要はありません。
うーん、私はこれを理解したかどうか確信が持てません。とにかく、ACL サービスはどのようにFacadeにマップされますか? おそらく、各 ACL サービスは、Facadeが公開する1 つの責任にマップされます(つまり、Facadeが 1 つの責任を公開する場合、 ACL サービスは 1 つしかありません。2 つの責任を公開する場合、2 つの ACL サービスがあります)。
3)
著者は、外部システムを単一の責任を持つものとして表現するのは意味がないかもしれないと言っていますが、代わりに、そのシステムは複数の責任を持つものとして表すことができるので、これらのそれぞれに対して ACL Facade + ACL サービス (および対応する Adapter ) を定義します。責任？
はい、外部システムはシステム内で異なる役割を果たす場合があります。そのため、ACL では複数のサービスとして表すことができます。ACL サービスごとに追加のサービスを定義する必要はありません。それらはすでにサービスになっています。
Udi の Making Roles explicitをまだ聞いていないことを認めなければならないので、ここで少し途方に暮れていますが、既にあるACL サービスごとに追加のACL サービスを追加する必要があることを暗示しているわけではありません。代わりに、作成者が責任ごとに 1 つの ACL サービスを持つべきかどうかを尋ねていました (つまり、他のBC/Facadeに1 つの責任がある場合は 1 つのACL サービスを定義する必要があり、 2 つの責任がある場合は2つの ACL サービスを定義する必要があります) 。
4)
正しい。ただし、ローカルで開発された 2 つの BC 間の関係は、外部システムの関係とは異なる場合があります。
どう違う？
2 番目の更新:
1)
a)
Ⅱ．
ファサードは、外部システムの API をカプセル化します。API によって提供される機能が 1 つの BC によってのみ使用され、複数のユース ケースがある場合、その BC に対して 1 つのファサード サービスを使用してもかまいません。別の方法は、ユースケースごとにファサードを作成することです。これも問題ありませんが、私が言ったように、最初のアプローチの技術的な結束は有益かもしれません.
Q1 -責任の代わりに「ユースケース」という用語を使用しています。「ファサードが単一のユースケースを公開する」と言うことは、一般的にファサードが単一のメソッドを公開することを示唆しているのに対し、「ファサードが単一の責任を公開する」ということは、ファサードがいくつかのメソッドを公開することを意味する可能性があると仮定するのは正しいですか。仕事 ）？
Q2 - では、ファサードは責任またはユースケースを公開する必要がありますか?
V.
通常、機能的な結束は、技術的または論理的な結束よりも優先されます。ただし、一般的には、両方が混在しています。技術的な結束は、小規模な場合に便利です。たとえば、同様のシリアル化または変換メカニズムをファサードで使用できます。それらをファサード間で共有することは便利ですが、機能的な結束を犠牲にすることはありません。したがって、そのような機能を 1 つの BC 内で共有することは問題ありませんが、BC 間で共有することは問題ありません。
遠くから見ると、機能的結束ではなく技術的結束を持つ単一のファサードが理にかなっています。しかし、このプロセスが実際にどのように見えるかはかなり混乱します。説明すると、外部システムがいくつかの責任を公開すると仮定すると、外部システムによって提供されるすべての責任を公開する単一のファサードを持つだけで、機能的結束ではなく技術的結束を持つようにファサードを設計できます。
しかし、外部システム(したがってFacade ) が単一の責任のみを公開するシナリオを想像するのはさらに困難です。そのようなシナリオでも、機能的結束ではなく技術的結束を持つようにファサードを設計することは可能ですか? はいの場合、簡単な例を挙げていただけますか?
Ⅵ．機能的結束は、副作用のない機能/純粋な機能に何らかの形で関連していますか?
2)
b)
とにかく、ACL サービスはどのように Facade にマップされますか? おそらく、各 ACL サービスは、Facade が公開する 1 つの責任にマップされます (つまり、Facade が 1 つの責任を公開する場合、ACL サービスは 1 つしかありません。2 つの責任を公開する場合、2 つの ACL サービスがあります)。
ACL は、サービスで構成されるファサードです。そして、はい、あなたの仮定はそれを行うための受け入れ可能な方法です. ここでのファサードという用語は、単一のクラスを指すのではなく、腐敗防止レイヤーを構成するクラス (サービス) のセットを指すことを意味します。1 つのクラスだけの場合もあれば、複数のクラスの場合もあります。
私はあなたが何を意味しているのか理解していると思いますが、念のために言っておくと、BCが1 つの外部システムとのみ通信しているため、 Facade が1 つしかないと仮定すると、Facadeは通常、単一のクラスとして実装されますか?
Ⅱ．ところで、ACL サービスはこの Facadeを直接呼び出すのではなく、対応するAdaptersのメソッドを呼び出し、次にこの Facadeのメソッドを呼び出すと思いますか?
III.
そして、はい、あなたの仮定はそれを行うための受け入れ可能な方法です.
つまり、外部システムが2 つの責任を公開する場合、両方の責任を公開する単一の Facadeを持つ必要があることを本質的に示唆していますが、一方で、責任ごとに 1 つずつ、2 つの ACL サービスを用意する必要があります。
3 番目の更新:
あなたの答えは私を非常に混乱させたので、あなたの答えに応じて意味のある質問をする前に (このトピックと私が作成した他のトピックの両方で)、次の質問をしなければなりません:
私があなたの答えを理解している限り、ACLサービスがFacadeを構成していると本質的に言っているようです。つまり、これらのACLサービスは Facade のインターフェースを表しているということですか? Facade はBC のドメイン モデルで表現されているため、これはBC に属していることを意味します(理由は、ACL サービスがBC のドメイン モデルで表現されているためです)?!
しかし、Evans は、Facadeは他のシステムの BC に属し(したがって、外部システムのドメイン概念を使用して表現する必要があります)、ACL サービスはBCに属する必要があり、BC のドメイン概念を使用して表現する必要があると主張しています。
ページ。367:
Facade は他のシステムの BC に属します
それで、私はあなたの投稿を誤解しましたか、それともこの件に関するあなたの意見はエヴァンスの意見と少し異なっていますか?
ありがとうございました