問題タブ [onion-architecture]

Udi Dahan の Domain Events - Salvation articleで規定されているように、ドメイン イベントを実装しました。

私が理解している限りでは、ドメイン イベントは、発生元のスレッド (通常はドメイン モデルまたはサービス) に対して非同期で実行できます。

何らかの「共有」作業単位やリポジトリ実装は必要なく、トランザクションの一貫性も必要ありません。

質問: Udi が別のスレッドでドメイン イベントの処理を実装していないのはなぜですか?

たとえば、Taskイベントを非同期に処理するために の作成を追加しました。

これから発生する可能性のあるマルチスレッドの問題はありますか?

編集: これらのドメイン イベントは軽量ですが、これは MVC Web プロジェクトであるため、IIS で引き続き実行されることに注意してください。

私はドメイン駆動設計を始めたばかりで (職場にドメイン駆動設計の使用を勧める担当者がいます)、見たものは気に入っています。タマネギのアーキテクチャは理解しています。これは DDD と密接に関連していると思いますが、それが Bounded Contexts でどのように機能するかはわかりません。

マイクロソフトの紹介で、境界付けられたコンテキストの必要性を理解しています

DDD の概要

しかし、これらが個々のタマネギであるかどうかはわかりません。あたかも 1 つの大きなタマネギの中に他のタマネギが入っているかのように、いくつかの交差があるように見えますが、これを実装するのは難しいように思えます。

タマネギのアーキテクチャ パート 1

タマネギのアーキテクチャは境界付けられたコンテキストでどのように機能しますか?

これは、Onion Architecture を実装する最初の試みです。

1. 上記のフォルダは正しいですか？
2. DependencyResolution プロジェクトの場所は Domain フォルダーにありますか?
3. インフラストラクチャ内の各プロジェクトには、コア プロジェクト内のインターフェイスを、それが含まれているプロジェクト内の実装に登録する DependencyRegistrar ファイルを含める必要がありますか?
4. WebApi プロジェクトを Presentation->Api に配置する必要がありますか? プレゼンテーションですか？
5. 各プロジェクトのすべての単体テストを「Tests」フォルダーに配置する必要がありますか?

前もって感謝します。

現在のプロジェクトに適したアーキテクチャを取得するのに苦労しています。ソフトウェア エンジニアリングのベスト プラクティス (DI、単体テストなど) を使用しようとして本格的な n 層アプリを設計するのは初めてです。私のプロジェクトは Onion アーキテクチャを使用しています。

私は4つのレイヤーを持っています

1. コア層: ビジネス オブジェクトを保持しています。ここには、ビジネス エンティティをメソッドで表すクラスがあります。これらのオブジェクトの一部には、サービス インターフェイスへの参照があります。

2. DAL (データ アクセス) レイヤー : POCO オブジェクトを定義し、コア レイヤーで定義されたリポジトリ インターフェイスを実装します。このレイヤーでは、POCOs オブジェクトを DAL から Core のビジネス オブジェクトに変換する役割を持つ大きなユーティリティ クラスを設計するのは良い考えだと思いました。

3. サービス層 : コアで定義されたサービス インターフェイスを実装します。この層の役割は、DAL で定義されたリポジトリへのアクセスを提供することです。このレイヤーは役に立たないと主に信じていたので、コアレイヤーで定義されているリポジトリインターフェイスを直接使用しました。しかし、非常に長いインスタンス化コードの作成に数週間費やした後、コンストラクターに 5 ～ 6 個の IRepository パラメーターを使用させた後、Service Layer の要点を理解しました。

4. プレゼンテーション層。ここで特に言うことはありませんが、このレイヤーで依存性注入を構成することを除いて (私は Ninject を使用しています)。

アーキテクチャを変更し、少なくとも 3 回はコードを書き直しました。これは、コードに何か問題があることに何度も遭遇したためです。(長いパラメーター リストを持つ長いコンストラクターのようなもの)。幸いなことに、私は文献に見られるさまざまなコーディング パターンの要点を理解しています。

しかし、私は DI で周期的な依存関係に遭遇したばかりで、私の DAL2Core ヘルパーが良いアイデアであったかどうか真剣に考えています...

このヘルパーのおかげで、次のようなコードを書くことができます:

これにより、コードの冗長性が少し軽減されます。次に、DAL で定義された各リポジトリには、独自の DAL2Core メンバーがあります。

そして、それを Repository コンストラクターから注入します。

DAL2Core クラス自体は少し面倒です... まず、すべてのリポジトリとすべてのプロセッサ (サービス層) のプロパティがあります。プロセッサが存在する理由は、コア オブジェクトにプロセッサの依存関係を挿入する必要があるためです。説明のために、DAL2Core ユーティリティ クラスで参照されているリポジトリとプロセッサの一部を以下に示します。

(DAL2Core ヘルパーはリポジトリで必要とされるため、コンストラクター インジェクションは循環的な依存関係を引き起こします)

そして、このクラスには次のような単純なメソッドがたくさんあります。

このクラスは 600 百行のようなものです。考えてみると、多くの場合、DAL2Core 変換コードは 1 か所からしか呼び出されないため、あまりコードを保存していないことに気付きました。おそらく、このコードはリポジトリに残した方がよいのではないでしょうか? そして、最大の問題は、このヘルパーをリポジトリ クラスから切り離すことにしたため、Ninject によって周期的な依存例外がスローされることです。

私が試したデザインについてどう思いますか、それは良い/一般的な方法ですか? そして、この DAL2Core 変換をコードのにおいを気にせずにスマートかつ効率的に実行するにはどうすればよいでしょうか。私はこのアーキテクチャの問題を解決することを本当に楽しみにしています。私はこの 3 週間、配管とアーキテクチャの問題に対処し、そのプロジェクトを実際には進めていませんでした。私は非常に遅くなってきています。しかし、私は本当に高品質のコードを作成したいと考えています。多くのファクトリなどを使用して、やり過ぎに見えるアーキテクチャソリューションを避けたいだけです...しかし、この感覚は、私からの理解の欠如から来る場合があることを認めます（サービスレイヤーの場合のように）。

よろしくお願いいたします。