次の各レイヤーは、隣接するレイヤーと密接に接続されており、使用されるインフラストラクチャモジュールとサービスに依存します。 多層アーキテクチャの主な欠点は、それによって生成される高い接続性です。 ご存じのように、高い接続性の最悪の兆候は、データアクセス層へのUIおよびビジネスロジック要素の浸透です。 マルチレイヤーアーキテクチャを使用するプロジェクトでは、UIはデータアクセスレイヤーと密接に関連付けられたままです。 移行依存は依存のままです。 ビジネスロジックレイヤーがデータアクセスレイヤーとは別に機能できないのと同様に、UIレイヤーはビジネスロジックレイヤーとは別に機能することはできません。 インフラストラクチャはプロジェクトごとに変化する傾向があるため、意図的にインフラストラクチャの問題を無視しています。 データアクセス層は常に変化しています。 歴史的に、データアプローチは少なくとも3年ごとに更新されます。 したがって、ライフサイクルが長いアプリケーションでは、3年以内にデータアクセスレイヤーに変更を加える必要があるという事実に備える必要があります。 接続性が高く、古いモジュールを相互に独立して交換することが困難な場合、システム全体が衰退状態に陥り、チームは完全に書き換えるしかありません。
アプリケーションを構築するための新しいアプローチを提案します。 正直に言うと、完全に新しいものではありませんが、名前を付けて、他のアーキテクチャパターンと同等に修正することを提案します。 パターンは、開発者に公開辞書を提供してコミュニケーションを簡素化するので便利です。 オニオンアーキテクチャには多くの側面があり、より効率的なコミュニケーションのために名前を付ける必要があります。 次の図は、タマネギのアーキテクチャを示しています。
接続の管理における主要な機能。 基本的なルールは、どのアプリケーションモジュールも電球の中心に近いモジュールに依存することができますが、より遠いモジュールに依存することはできないということです。 言い換えれば、接続性は電球の中心に向けられるべきです。
オニオンアーキテクチャはOOPに引き寄せられ、アプリケーションの他の側面よりも先にオブジェクトを配置します。 まさに中心にあるのは、アプリケーションのドメインモデルです。 ドメインモデルの周りには、追加のビジネスロジックを持つ他のレイヤーがあります。 アプリケーション内のレイヤーの数はさまざまですが、ドメインモデルは常に中心にとどまる必要があり、接続性はすべてセンターに向けられるため、ドメインモデルはそれ自体とのみ接続されます。 ドメインモデルの最初の層は、リポジトリインターフェイスが通常配置される場所であり、オブジェクトの保存と取得を保証します。 オブジェクトを保存するプロセスは、アプリケーションカーネルの外部に配置されることに注意してください。このプロセスは、通常、データベースサーバーとの対話を伴い、インターフェイスのみがカーネルの中心にあるためです。 アプリケーションの外側には、UI、インフラストラクチャ、およびテストがあります。 外側の層は、頻繁に変化する要素のために予約されています。 これらの要素は、アプリケーションコアから分離する必要があります。 最先端には、リポジトリインターフェイスを実装するクラスがあります。 これらのクラスは特定のデータアクセステクノロジーと密接に関連しているため、アプリケーションコアの外部に移動する必要があります。
オニオンアーキテクチャは、依存関係の反転の原理に基づいています。 アプリケーションには、カーネルにあるインターフェイスの実装が必要です。特定の実装はアプリケーションの外部半径にあるため、アプリケーションには依存関係を注入するメカニズムも必要です。
データベースはアプリケーションセンターにありません。 カーネルから別のモジュールにデータベースエンジンを転送することは、データソースとのやり取りのコンテキストでのみアプリケーションについて考えている人にとって、深刻なステップになる可能性があります。 もちろん、アプリケーションはデータベースを使用してオブジェクトを保存できますが、アプリケーションコアで使用されるインターフェイスを実装するインフラストラクチャコードのレイヤーを介してのみです。 アプリケーションとデータベース、ファイルシステムなどの間の接続の切断。 ライフサイクル全体を通してアプリケーションをサポートするコストを削減します。
アリスター・コックバーンはかつて彼のブログで六角形の建築について書いた。 六角形およびタマネギのアーキテクチャは、一般的な原則に基づいています。インフラストラクチャを外部モジュールに転送し、アダプタをそれらに書き込みます。 エンタープライズレベルのアプリケーションを構築する際のタマネギアーキテクチャの使用についてさらに詳しく説明する予定です。 私はこの環境にとどまり、このコンテキストでのタマネギアーキテクチャのトピックに関する議論を続けます。
翻訳者から。 この投稿は、タマネギアーキテクチャに関するジェフリーパレルモの一連の投稿の最初の投稿です。 habrasocietyに関心があれば、残りの部分の翻訳を行うことができます。