オニオンアーキテクチャ：ビジネスロジックのレイヤー配置
Onion Architectureを利用するプロジェクトのビジネスロジックはどこに配置する必要がありますか？
私の場合、それはC＃ベースのプロジェクトで、Web APIを利用し、プレゼンテーションにMVC UIを使用している可能性があります。しかし、私はこれを概念的に興味があるだけなので、それは問題ではないかもしれません。
以下の2つの図は、オニオンアーキテクチャに関する情報をグーグル検索しているときにWeb全体に表示される最も一般的な図のようです。
私が間違っていない場合、外輪の下にあるものはすべてコアと見なされます。
Diagram＃1では、コアの最も外側（青いリング）にサービスインターフェイスが含まれており、紫の外側リングにロギング、サービス、など。それでは、外側の紫色のリングにサービスレイヤーとビジネスロジックが含まれているということですか。
Diagram＃2では、アプリケーションとドメインサービスがアプリケーションコアの一部として示されています（インターフェースとドメインモデルだけではありません）。
私はこれらの2つの図がオニオンアーキテクチャを完全に異なるように定義しているように感じますが、それでもそれらは主に参照されている2つであるようです。それとも私はこれを間違って読んでいますか？
たぶん最終結果は同じで、私が頭の中でプロジェクトレイアウトをどのように見ているかだけの問題ですが、サービスレイヤーを外輪のインフラストラクチャの一部。それはそれを考えるのに間違った方法ですか？
サービスレイヤークラスには、リポジトリやその他のサービスクラスを挿入できます。サービス自体をプレゼンテーション層プロジェクト（Web APIやMVCコントローラーなど）に注入し、そこからAutomapperを介してプレゼンテーション可能なオブジェクト（DTOまたはViewModel）に変換できます。
ありがとうございました
ここでレイヤードアーキテクチャで通常「ビジネスレイヤー」と呼ぶものは、ドメインモデルと呼ばれることもありますが、それは重要ではありません。
リングに別のリングが含まれていて、それは概念的なエラーだと言います：任意の外部リングが内部リングと通信し、コア付き。明らかにUIにはドメインロジックが含まれていません（テストにはアプリケーションサービスが含まれていないため）。
従来の階層化アーキテクチャとの違いは、依存関係のスケッチに使用する形状よりも根本的であり、この場合、このメモ可能な名前（および形状）は、基本的な違いを把握するのに実際には役立ちません。ドメインモデルは、システム全体。重大な違いに注意してください。UIはドメインモデルを使用します。これは、アプリケーションサービスリングに限定されません（どの画像が誤って考えるように誘導される可能性があります）。それは直接の依存関係があることを意味しません：インターフェイスとIoCは必要な抽象化と分離を提供するために配置されています、コアポイントは各リングを分離することではなくを分離することです外部エンティティのドメインモデル。
ビジネスロジックは、実際にはどちらか一方で2種類に分けられます。
Data | Domain Entities | Domain Model
Data Business Logic | Repository Interface | Domain Service
Software Environment Business Logic | Service Interface | Application Service
データビジネスロジックは、最も純粋で最も抽象的なビジネスロジックです。ここで、年齢などは生年月日とタイムスタンプから導き出されます。ここでは、ドメインの専門家にとって意味のあるものだけが存在することが許可されています。
ソフトウェア環境ビジネスロジックは、ドメイン以上のものを認識できます。ソフトウェアの存在を認識し、そのためのハウスキーピングを行う場合があります。たとえば、年齢を特定の言語の数字として、進行状況バーの％として、または長いひげのある漫画の絵として表現したりします。
このようなビジネスルールを分割するのは、オニオンアーキテクチャだけではありません。クリーンアーキテクチャでも同じことがわかります1：
ビジネスロジックは、両方の図（ドメインモデル/ドメインエンティティ）の内側の円です。これは、意味のある処理が行われる場合、残りは単にシステムを機能させるための配管です。
左の図は、リポジトリパターンの適用を想定しているため、用語が異なります（リポジトリインターフェイスとドメインサービス）。基本的に写真は同じです。
ビジネスロジックは、いわゆる3層アーキテクチャーのレイヤーを識別するために使用される用語です。これは、Webアプリケーションの追加の複雑さを欠き、通常、下部/コアにリレーショナルデータベースを持つ古いシステムによく使用されるモデルです。 3層には、プレゼンテーション、ビジネスロジック、ストレージがあります。後者のレイヤーは、上の図では面白くないので無視されています。アーキテクチャの説明のために、データや動作を処理しているかどうか、システムが最終的に何をしているのかは関係ありません。