7

私はオニオンアーキテクチャを学ぼうとしていますが、私が理解しているように、次のようにソリューションを整理しました:

ドメイン

  • Domain.Entities (ビジネス オブジェクト)
  • Domain.Interfaces (ドメイン サービスとリポジトリのインターフェイス)
  • Domain.Services (ドメイン サービス インターフェイスの実装)

インフラストラクチャー

  • Infrastructure.Data (EF を使用したリポジトリと作業単位の実装)
  • Infrastructure.DependencyResolution (UnityによるIoCの実装)

UI

  • UI.WebMVC

そして、ここに私の質問があります：

1-これらのレイヤーで正しいですか、それとも何か不足していますか?

2- 特定のテクノロジー (ロギングなど) に関連するサービスについては、そのインターフェースはどこにあるべきか (Domain.Interfaces または Infrastructure.Interfaces) ?

3-私が理解しているように、ドメインサービスは私のビジネスユースケースを処理します。アプリケーションサービスから得られる利点は何ですか

4- Domain Service と Application Service の違いは何ですか? また、Application Service インターフェイスはどのプロジェクトに配置する必要がありますか?

5- ユーザー認証プロセスは、アプリケーション サービスまたはドメイン サービスの一部にする必要がありますか?

4

1 に答える 1

2

ここに画像の説明を入力

  1. これは六角形アーキテクチャのスキーマですが、タマネギに非常に近く、IMO を使用する必要があります。ここでは、ドメイン (黄色)、アプリケーション (赤)、インフラストラクチャ (緑 + 青) の 3 つのレイヤーが示されています。あなたの質問に答えると、アプリケーションサービスのようないくつかの部分が欠けています。

  2. ロギングはおそらくドメイン ロジックの一部ではないため、インターフェイスと実装の両方のインフラストラクチャに含める必要があります。それを使用するには、アプリケーション層に注入する必要があります。

  3. ドメイン サービスは、お客様のビジネスに関連することのみを処理します。アプリケーション サービスはほとんどの場合、ドメイン サービスの準備をします。たとえば、リポジトリを作成してそこから集計を取得し、ドメイン サービスを呼び出してそこに集計を渡します。ビジネス ロジックをアプリ レイヤーで処理するべきではありません。

  4. ポイント 3 で書いたように、アプリケーション サービスは、ドメイン サービスを使用しているすべてのプロジェクトに存在する必要があります。

  5. 依存します。ユーザーはユーザー資格情報を使用してインフラストラクチャ レイヤーを要求し、インフラストラクチャ レイヤーはその資格情報を使用してアプリケーション レイヤーを呼び出します。そこで、指定された資格情報でユーザーを取得しようとしますが、最初に生のパスワードをいくつかの関数でハッシュ化されたパスワードに変換します。ユーザーが見つかった場合は、インフラストラクチャ レイヤーでユーザーを認証できます。ここではドメイン サービスは必要ありませんでしたが、これは例外です。

于 2014-09-15T13:38:56.633 に答える