domain-driven-design - TranslationレイヤーとAntiCorruptionレイヤーの実装の違い

Question

1. 概念的には、 TranslationレイヤーとAntiCorruptionレイヤーの違いは理解していますが、実装に関する限り、Translationレイヤーにはファサードがなく、Translationレイヤー内にサービスも存在しないという2つの違いがあります。アダプタがありますが、代わりにドメインコード自体（Bounded Context内にある）がトランスレータを呼び出しますか？

2. a。外部システム ESが実際に別のアプリケーションの一部であり、アプリケーション層を介してドメイン層から直接機能（Bounded Context BCが必要とする）を提供する場合、 BCは必要なサービスをどのように要求する必要がありますか？ESのアプリケーション層と通信することによって、またはESのドメイン層と（変換/腐敗防止層を介して）通信することによって？

   b。BCがESのアプリケーション層を介して機能を要求するときに、変換/アンチコラプション層も必要ないのはなぜですか。ESのアプリケーション層を介して受信するデータは、ドメインの概念に変換する必要があるためです。

   c。ESが実際に私たち自身のアプリケーションの一部である場合、私は、 BCがTranslation / AntiCorruptionレイヤーを介してESの ドメインレイヤーと「直接」通信することによって機能を要求することしかできないと思いますか？

Answer 1

1. 変換は、ACL が行うことです。これらは別個の概念ではありません。実装はさまざまな方法で行うことができます。ただし、重要なのは、ドメインを外部システムから保護することです。ACL は、外部システムのモデルをローカル ドメイン モデルに変換することでこれを行います。

2a. ローカル BC は、アプリケーション サービスまたは基本的に Web サービスであるオープン ホスト サービスを介して、外部 BC と通信する必要があります。前者のアプローチは、2 つの BC が連携して開発され、両方を実装する直接ライブラリがある場合にのみ実行可能です。後者は、サードパーティの BC またはサービスによって完全にカプセル化された BC に適用されます。

2b. 2 つの BC が並行して開発され、共有カーネルを持っている場合を除き、これは依然として発生する必要があります。ただし、私は共有カーネルの大ファンではありません。

2c。BC は、ES のアプリケーション サービスを介して ES と通信する必要があります。ドメイン オブジェクトに直接アクセスしないでください。さらに良いことに、BC が呼び出す Web サービスによって ES 機能を公開します。