Onionプロジェクトの構成方法
Onionアーキテクチャを使用した実装例を以下に示します。 https://www.codeproject.com/Articles/1028481/Understanding-Onion-Architecture
このWebページは、次のソリューション構造を提案しています。
Domain - Solution Folder
Domain.Entities - Class Library Project
Domain.Interfaces - Class Library Project
Service Interfaces - Solution Folder
Service.Interfaces - Class Library
Services - Solution Folder
Services - Class Library Project
Infrastructure - Solution Folder
Infrastructure.Data - Class Library Project
User Interface - Solution Folder
MVC - MVC Project
少し質問があります：
サービスレイヤーに2つのソリューションフォルダーがあるのはなぜですか？つまり、サービスとサービス、インターフェース。私はドメインレイヤーに1つのようなものがあるはずです。つまり、ドメインソリューションフォルダーには2つのクラスライブラリプロジェクト（Domain.EntitiesとDomain.Interfaces）が含まれています。私は通常これを間違いだと思いますが、そのように構成された他のプロジェクトを見てきました。
ドメインとサービスレイヤーが2つのクラスライブラリプロジェクトに分割されるのはなぜですか（クラスとライブラリを含むそれぞれに1つのクラスライブラリプロジェクトがないのはなぜですか）。
この質問 は、すべてのインターフェースをドメイン層に含める必要があることを示しています。ただし、これまでに見てきたすべてのコードサンプルでは、サービスレイヤーインターフェイスをサービスレイヤーに配置しています。彼らはサービス層またはドメイン層に行くべきですか？
モデル/レイヤーはプロジェクト/ APIの境界を置くための自然な場所を示唆していますが、プロジェクト/フォルダーの観点からOnionアーキテクチャーを確立するために必要なものは何もありません。
この図を見てください：
これを見てください：
図の形以外に、何か面白いことに気づきましたか？
これら2つの図の唯一の重要な違いは、オニオン図は、データアクセスレイヤーを介したデータベースへのアクセスのみを許可するということです。「従来のレイヤードアーキテクチャでは、 "UIとビジネスロジックは、データベースや他のITシステム（作成者が"インフラストラクチャ "と呼んでいるもの）への直接アクセスを許可されています。 Onionアーキテクチャでは、データベースへのアクセスが許可されているのはドメインエンティティのみです。このアーキテクチャとの相互作用のほとんどは、サービスレイヤー境界（外部リング）で発生することに注意してください。
オニオンアーキテクチャについては以上です。ここでは、レイヤー間の厳密な分離以外に特別なことはありません。実際、オニオンのやり方は、今日のビジネスドメインソフトウェアアーキテクチャが最も一般的に表現されている方法だと思います。この作者が「従来のレイヤード」と呼んでいるものに似たアーキテクチャを見つけるには、WinformsまたはASP.NET（どちらも広範囲にコードビハインドを使用しています）に戻る必要があります。
ソリューション/プロジェクトの構造は、タマネギのアーキテクチャーによって決定されません。非常に単純なアプリケーションを使用している場合は、同じプロジェクト内にすべてを含めることができ、同じフォルダーを含めても、完璧なオニオンアーキテクチャを維持できます。または、100のプロジェクトがあり、それでもタマネギのアーキテクチャを維持することができます。
アーキテクチャは、コードを別々のプロジェクトに配置する必要がある場合にコードを分離するのが自然である「継ぎ目」を提案しますが、表示される構造は単なる例です。実際には、依存関係とデプロイメントの考慮事項に応じて、プロジェクトに分離します。