タマネギとN層アーキテクチャ
事前に1つ：私はN層の背景から到着します。
私は今、Onion Architectureと、Hexagonal Architectureなどの関連するドメイン駆動の概念について頭を悩ませています。 Jeff Palermoの一連のブログ投稿 、 DIからのMarkSeemannの貢献-perspective 、 "オニオン化するアーキテクチャ" 、および "クリーンなアーキテクチャ" 。
これらの記事すべてに共通しているのは、次の点を主張しているということです。
- ビジネスユースケースのドメインモデルに焦点が当てられています
- 依存性逆転の原則を強調することによる層間の疎結合
- フレームワーク、データの永続性、UIなどの外部インフラストラクチャの独立性の向上
- テスト容易性/保守性の向上
まあ、それはすべて信じられないほど素敵に聞こえます、そしてそれらの図も同様に甘く見えます。しかし、私に生じる疑問は、従来のN層アーキテクチャにファサードを追加するだけですべてが達成されるのではないかということです。
- 各レイヤーは、下のレイヤーの抽象化を知っているだけです
- 具体的な実装は各レイヤーの内部に保持できるため、抽象化と同じ場所にあります
- 実装の詳細はレイヤーの内部にあり、アプリケーションの他の部分に影響を与えないため、簡単に交換できます。
ドメイン中心のアーキテクチャの真の利点を理解するのを手伝ってください。
前もって感謝します！
ファサードを追加することは、実際には、n層アーキテクチャからタマネギアーキテクチャを構築するための最初のステップです。だから、はい、あなたはすぐに多くの利点を得ることができます。
依存関係の制御を逆にする必要があるため、テストにはまだ問題があります。ファサードが指しているものを制御することは、プロバイダーではなく、コンシューマーに移動する必要があります。これにより、コンシューマーはテストのために物事を交換したり、プロバイダーがそれについて知らなくても実装を変更したりできます。
私はあなたと同じ意見を共有しています。新しいプロジェクトを開始する予定で、同僚の1人がタマネギのアーキテクチャを提案しましたが、それについて少し文書化した後、（私にとっては！）少し混乱しました。各クライアントレイヤーが使用されるレイヤーの抽象化のみに依存する必要があるという事実は、使用する予定のアーキテクチャーを常に念頭に置く必要があるベストプラクティスの問題です。DIはアーキテクチャーではなく「原則」であるため、 「good OO Principles」でN層アーキテクチャを使用するだけで、どのように新しいアーキテクチャになるのか理解できますか？
このようにして、すべてのOOプリンシパルとGo4パターンをエンタープライズアプリケーションアーキテクチャに結合するだけで、何百もの新しいアーキテクチャで終わります。
あなたの質問に直接答えるために、「それはすべて、私の伝統的なN層アーキテクチャにファサードを追加するだけでは達成されませんか？」ユースケースに応じて、答えは「はい」と「いいえ」です。
依存性逆転の使用に関するOnionアーキテクチャの焦点は、あなたが言ったように...「疎結合を作成する」ことです。しかし、それは敗者のカップリングのためだけではありません。 「変更される可能性が最も低い部分から、変更される可能性が最も低いコードの部分を保護する」と考えると役立つ場合があります。それで、あなたの場合、ファサードの「下」の変更はあなたの「ドメイン」コードの変更を必要としますか？たとえば、データベースオブジェクトへの変更は、ファサードで使用されているオブジェクトへの変更、次に「ドメイン」コードへの変更に少しずつ入りますか？これらのタイプの質問に対する答えが「いいえ」の場合、あなたの仮定は正しいです。そのコードに意味のある機能上の違いはありません。誰かが「たぶん」と答えた場合、ファサードからIOCへのリファクタリングの恩恵を受ける可能性があります。