上の 2 つの画像は、Onion Architecture についての私の理解を表しています。それらは、私が答えを見つけることができない議題に対処しているため、オンラインで見つけた図面とは少し異なります。
私が知る限り、インフラストラクチャとは永続性やロギングなどです。それらの例をイタリック体で書きました。ただし、多くの場合、インフラストラクチャ コンポーネントと UI は相互に通信する必要があります。UI は何かを監査またはログに記録したい場合があり、永続化プロジェクトは何かをログに記録する必要がある場合があります。ロギングは、オニオン アーキテクチャに適合させるのが難しい項目の 1 つです。私の理解では、ログを記録する必要がある場所とすべきでない場所について、多くの人が異なる意見を持っています。
最初の図では、図にインフラストラクチャ インターフェイス レイヤーを配置して、1 つのコンポーネントが別のコンポーネントの実装を認識しなくても相互通信できるようにしました。これは、私がいくつかの例で見たものです。
2 番目の図は私の好みです。メディエーターを使用して、インフラストラクチャ、UI、およびコア サービスがインフラストラクチャと間接的に通信できるようにする基本的な方法の間で相互通信します (右側の図ではサービス インターフェイスがコア サービスと呼ばれていると仮定します)。ロガーは、データベースなどと同様に、特定のイベントにサブスクライブします。
最初の図では、外側のレイヤー (依存関係リゾルバーを除く) を除くすべてのレイヤーで poco とインターフェイスのみが許可されます。2 つ目は、コア サービス レイヤーでドメインとビジネス ロジックを許可し、インフラストラクチャ レイヤーが分離してジョブを実行できるようにします。
何らかの出力が得られるようにすることで、インフラストラクチャ コンポーネントを正当化しました。監査とロギングは通常、ある種のデータベースを使用し、キャッシュは通常メモリに保存され、データベースはおそらく永続性と呼ばれるべきでした。ただし、AutoMapper というライブラリがあります。いくつかのインスタンスでラップされているのを見たことがあります。そのため、そのインターフェイスはコアに入ってほとんどすべてのインフラストラクチャで使用できますが、私には抽象化されすぎているように思えます。Automapper は、すべてのインフラストラクチャが自身とドメインの間の変換に使用するという点で Events オブジェクトに似ていますが、サービスではないため、そのレイヤーに適合するかどうかはわかりません。
質問: 2 つのうちどちらがオニオン アーキテクチャの定義に最も近く、自動マッパーのようなツールのどこに当てはまりますか?また、そのようなものをラップしようとすることは抽象化を超えていると思いますか?
ありがとう！