0

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/Facade1 つの責任がある場合は 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 に属します

それで、私はあなたの投稿を誤解しましたか、それともこの件に関するあなたの意見はエヴァンスの意見と少し異なっていますか?

ありがとうございました

4

1 に答える 1

2

1a) ファサードが同じプロジェクトで使用され、異なる責任が依然として同じ境界コンテキストに分類される場合は、同じファサードを使用します。外部システム API 軸に沿った技術的結束の利点は、責任軸に沿った機能結合の利点を上回ります。

1b) ファサード自体は事実上、サービスまたはサービスのセットです。追加のサービスを定義する必要はありません。

2a1) はい。

2a2) はい。ただし、軽蔑的な意味での漏洩とは言えません。ACL の目的は、外部モデルをローカル ドメイン モデルに適合させることです。したがって、当然、ドメインの概念が存在します。

2b) ACL サービスは、外部システムと BC の間のみを仲介する必要があります。ただし、この調停の性質は拡大することができます。中心的な目標は、外部モデルの変更に起因する破損から保護することです。

3) はい、外部システムはシステム内で異なる役割を果たしている可能性があります。そのため、ACL では複数のサービスとして表すことができます。ACL サービスごとに追加のサービスを定義する必要はありません。それらはすでにサービスになっています。

4) 正しい。ただし、ローカルで開発された 2 つの BC 間の関係は、外部システムの関係とは異なる場合があります。

アップデート

1a1) はい、タイプミスです。訂正しました。

1a2) ファサードは、外部システムの API をカプセル化します。API によって提供される機能が 1 つの BC によってのみ使用され、複数のユース ケースがある場合、その BC に対して 1 つのファサード サービスを使用してもかまいません。別の方法は、ユースケースごとにファサードを作成することです。これも問題ありませんが、私が言ったように、最初のアプローチの技術的な結束は有益かもしれません.

1a3) この場合、各 BC にファサードがあります。別の方法は、ファサードを共有しようとすることです。あなたが言ったように、これは依存関係の混乱になります。

1a4) はい。他の BC が別のアプリの一部である場合は、1a3 で説明されているように、その BC に固有の新しいファサードを作成します。

1a5) 通常、機能的結束は技術的または論理的結束よりも優先されます。ただし、一般的には、両方が混在しています。技術的な結束は、小規模な場合に便利です。たとえば、同様のシリアル化または変換メカニズムをファサードで使用できます。それらをファサード間で共有することは便利ですが、機能的な結束を犠牲にすることはありません。したがって、そのような機能を 1 つの BC 内で共有することは問題ありませんが、BC 間で共有することは問題ありません。

2b) ACL は、サービスで構成されるファサードです。はい、あなたの仮定はそれを行うための受け入れ可能な方法です。ここでのファサードという用語は、単一のクラスを指すのではなく、腐敗防止層を構成するクラス (サービス) のセットを指すことを意味します。1 つのクラスだけの場合もあれば、複数のクラスの場合もあります。

3) はい、それは著者が言っていることです。

4) これについては、本書の後のセクションでも説明します。ローカル BC の違いは、それらを開発しているチームがコミュニケーションを取り、モデルを調整して相手の要件を満たすことができることです。外部 BC の場合、これは不可能な場合があります。

更新 2

1a1) 「ユースケース」という用語は、「責任」と交換可能であることを意図していました。それらは、単一のメソッドまたはいくつかのメソッドを意味する可能性があります。

1a2) 責任という言葉の方が適切だと思います。

V.) 外部システムは確かに単一の機能しか提供できません。たとえば、通貨の為替レートを返すサードパーティ サービスを使用できます。メソッドは 1 つしかなく、異なるシステムで通貨と為替レートが表現される方法の違いを管理するために、ACL が配置されます。ただし、この場合、責任は 1 つしかないため、結束については考えていません。

VI.) いいえ。何らかの技術的側面とは対照的に、目前のドメインに沿って整列するのは一種の結束です。

2b1) 外部 BC をローカル BC に公開するドメイン サービスを実装する単一のクラスが必要です。ただし、このクラスは、シリアル化などのために他のクラスを使用できます。ただし、これらのクラスは、このサービス クラスの背後に「隠されています」。

2b2) ACL サービスは、ファサードを構成するものです。これは単なる用語の混乱かもしれません。ACL はファサードです。

2b3) 単一のサービスで両方の責任を公開することができます。このようにして、いくつかのコードを簡単に共有できます-技術的な結束。ただし、共有コードを 2 つの異なるサービスで使用できるユーティリティ クラスに抽出することもできます。私が言いたいのは、まだ単一の BC に限定されているため、最初のアプローチはひどいものではないということです。

于 2013-02-18T21:58:10.870 に答える