.net 論理階層化アーキテクチャの概要

1. 基礎知識の準備:

1. レイヤーの原理:

(1) 各レイヤーは上位レイヤーを呼び出すためのインターフェイスを使用します。
(2) 上位層は下位層のみを呼び出すことができます。
(3) 依存関係は、緩やかな相互作用と厳密な相互作用の 2 つのタイプに分類されます。

2. ビジネスロジックの分類:

(1) アプリケーションロジック。
(2)ドメインロジック。

3.採用層：

（1）プレゼンテーション層（ユーザーインターフェース層）：ドメインに依存しない。
(2)サービス層（アプリケーション層）：アプリケーションロジック。
（3）ビジネスロジック層（ドメイン層）：ドメインロジック。
(4) 共有レイヤー：共通コードを提供します。
(5)実装層：インターフェースの実装を提供します。

4. 合意事項:

(1) ドメイン層はデフォルトでドメインモデルを使用する
(2) データアクセス層はデフォルトでドメインモデルを参照する必要がある

2. 階層化アーキテクチャ

の 3 つの基本レベル階層構造には、プレゼンテーション層、ビジネス ロジック層、データ アクセス層があります。ビジネスロジック層をビジネスロジックの分類に従ってサービス層とドメイン層に分解すると、3層はプレゼンテーション層、サービス層、ドメイン層、データアクセス層の4層に拡張されます。データ アクセス層は通常、層間に双方向の依存関係を作成するドメイン モデルを理解する必要があります。通常、次の 2 つの解決策があります:

1. ドメイン モデルを共有層に配置します:

評価: PetShopこのモデルには多くの欠点があります。ビジネス ロジック層はその名前にふさわしくなく、ドメイン モデルは実際にはデータ モデルであり、層間の依存関係を維持し、より多くの依存関係を導入します。これには明らかなデータ駆動型のアイデアがありますが、そうではありません。ドメインに焦点を当てます。

2. ビジネスロジック層でデータアクセスインターフェースを定義する:

評価: NopCommerce はこのモデルを採用しており、サービス層が分離され、リソースライブラリの命名方法が採用されていても、NopCommerce は DDD ではありません。このアーキテクチャは、ドメイン モデルとインターフェイス分離の原則を採用した一般的な 3 層アーキテクチャです。欠点: データ領域を除けば、他の特定の技術的依存関係がビジネス ロジック層から分離されていません。

3. DDD レイヤ化:

DDD レイヤ化は、ビジネス ロジック層をアプリケーション層 (サービス層) とドメイン層の 2 つの部分に明確に分割します。同時に、データ アクセスやその他のインターフェイスの特定の技術実装部分がインフラストラクチャ層に統合されます。

1. 独自の DDD 階層化:

評価: 利点は、特定の技術実装がドメインから分離され、インフラストラクチャ層の再利用価値が高まることです。欠点は、共有と実装の概念がインフラストラクチャ レイヤーを細分化するために使用されていないため、インフラストラクチャ レイヤーでウェアハウジングを実装するときに逆依存関係が発生することです。ただし、単一プロジェクト ソリューションには影響がありません (名前空間レベルでの形式的な依存関係のみです)。 )、ただし、.NET マルチプロジェクト ソリューションでは、ウェアハウスの実装はインターフェイスの分離を通じてのみデータ アクセス層のようなメソッドに分離できます。

2. DDD 階層化の改善:

評価: インフラストラクチャ層は、共有層と実装層の両方の特性を備えています。利点は、最終的にコアとして正式なドメインを実現できることですが、同時に、インフラストラクチャ層でウェアハウジングを実装するときにドメイン モデルを参照できないという恥ずかしさを解決できることです。欠点は、概念間の区別も存在しないことです。共有と実装。

3. 最新の DDD 階層化:

評価：利点は、これが真にドメイン中心であり、インフラストラクチャ層がドメイン層を参照できないため、サービス層で再度適応する必要がないことです。依存関係反転の原則を使用して、特定のテクノロジーに対する各レイヤーの依存関係を完全に反転します。欠点: 依存関係の反転が過剰に適用されることも、単一プロジェクト ソリューションでは問題ありませんが、.NET マルチプロジェクト ソリューションでは、名前空間の形式で双方向の依存関係が発生します。インフラストラクチャ層は実装層としては基本的に再利用価値がありません。より良いアプローチは、図内のユーザー インターフェイス層とインフラストラクチャ層の位置を交換することです。

必要に応じて、上の画像に適切な共有レイヤーを追加することを検討してください。

4. アーキテクチャのトレンド:

(1) ビジネス ロジックを核として、ビジネス ロジックにさらに注意を払う。
(2) ビジネスロジック層の特定の依存関係を 1 つのレベルに分割し、一元管理します。
(3) ソリューション間でのコードの再利用よりも、ソリューション内の依存関係を減らすことに注意を払います。
④共有層と実装層の分離がますます反映される。たとえば、タマネギのアーキテクチャ。

参考

1.エンタープライズアプリケーションアーキテクチャのパターン【エンタープライズアプリケーションアーキテクチャパターン】
2.ドメイン駆動設計【ドメイン駆動設計：ソフトウェアの中核となる複雑さにどう対処するか】
3.ドメイン駆動設計の適用とパターン【フィールドドライバー設計とパターン実践】
4.ドメイン駆動設計の実装【ドメイン駆動設計の実装】
5.Microsoft Application Architecture Guide【Microsoft Application Architecture Guide (2nd Edition)】
6.Professional Enterprise .NET【熟練.NET エンタープライズにおけるプロジェクト開発: 最新のパターン、ツール、手法]
7.プロフェッショナル ASP.NET デザイン パターン [ASP.NET デザイン パターン]