問題タブ [onion-architecture]

エンティティ フレームワークを使用して作業単位を実装し、完全な単位が実行された後にのみ変更をコミットする方法を理解していますが、これをさらに一歩進めるにはどうすればよいですか? たとえば、次のすべてが 1 つのトランザクションで発生する必要があります

電子メールの送信とデータベース内のユーザーの保存がすべて 1 つのトランザクション内で確実に行われるようにする方法がよくわかりません。どんなアドバイスでも大歓迎です

集計の設計方法に問題があります。

、、およびエンティティがCompanyあります。これらはそれぞれ、独自の集約の集約ルートである必要があります。、およびエンティティはシステム全体で使用され、他の多くのエンティティから参照されるため、値オブジェクトではなく、さまざまなシナリオでアクセスする必要があります。したがって、リポジトリが必要です。Aには、、、、、、などのメソッドがあります。CityProvinceCountryCityProvinceCountryCityRepositoryFindById(int)GetAll()GetByProvince(Province)GetByCountry(Country)GetByName(string)

次の例を見てください。エンティティは、 に属する にCompany関連付けられています。CityProvinceCountry

ここで、いくつかの企業とその都市、州、および国を一覧表示する企業一覧ページがあるとします。

IDによる参照

エンティティがCity、Provinceまたはを参照する必要がある場合はCountry、ID で行います (Vaughn Vernon の提案による)。

リポジトリからこのデータを取得するには、4 つの異なるリポジトリを呼び出してから、データを照合してビューに入力する必要があります。

これは非常にかさばり、非効率的ですが、明らかに「正しい」方法ですか?

参照による参照

エンティティが参照によって参照された場合、同じクエリは次のようになります。

しかし、私が理解している限り、これらのエンティティは異なる集計に存在するため、参照によって参照することはできません。

質問

これらの集計をより適切に設計するには、他にどのような方法がありますか?

異なる集計に存在する場合でも、都市モデルを使用して会社エンティティを読み込むことはできますか? これはすぐに集計間の境界を壊すと思います。また、集計を更新する際にトランザクションの一貫性を処理する際にも混乱が生じます。

Shipping ContextとBilling Contextという 2 つの境界付けられたコンテキストがあるとします。これらの各コンテキストは、顧客について知る必要があります。

CustomerTblデータ レベルでは、顧客はデータベース内のテーブルによって表されます。このテーブルは、顧客を説明するために必要なすべての列で構成されています。

列CustomerTbl(簡略化):

• Name
• PhysicalAddress
• PaymentMethod

Shipping Contextは と に関係し、NameBillingコンテキストはと に関係します。PhysicalAddressNamePaymentMethod

Shipping Contextでは、集計をモデル化しましたRecipient。

• Recipientと のプロパティ/値オブジェクトが追加されましNameたPhysicalAddress

請求コンテキストでは、集計をモデル化しましたPayer。

• Payerと のプロパティ/値オブジェクトがNameありますPaymentMethod

RecipientとPayer集約の両方は、コンテキスト境界によって完全に分離されています。また、独自のリポジトリもあります。

質問:

1. 同じ「データベース テーブル」を使用して、複数の集計 (それらが別々の境界付けられたコンテキストにある場合) を持つことは許容されますか?

2. 顧客データは、より多くの限定されたコンテキストで必要になる可能性があります。これは、境界付けられたコンテキストごとに多くの集約、リポジトリ、およびファクトリの実装を意味するのではないでしょうか? コードにはある程度の冗長性があります。これは保守性に影響しませんか？

3. 集約間でプロパティを共有することは許容されますか? 例として、顧客のNameプロパティがあります。これは冗長な検証コードを意味しますか?

私は、Onion アーキテクチャ、Clean アーキテクチャ、Ports and Adapters などの名前を持つこの新しい種類のアーキテクチャを理解しようとしています。

ポートとアダプタを抽象化して、アプリケーションを特定のポートに適合させる場合、アプリケーション内からポートにエンティティを与えても問題ありませんか? または、ポートに合わせてエンティティも常に適応させる必要がありますか?

例：

Customer エンティティがあるとします。アプリケーションを使用する UI があります。私の UI は、Adapter を介して getCustomerById(123) を呼び出します。次に、アダプターがアプリケーションを呼び出し、注入されたリポジトリを使用して顧客を効果的に取得し、何らかのフォーマットとログを実行します。顧客の準備が整うと、UI に返されます。ここでの私の質問は、Customer オブジェクトがそのまま UI に返されるということです。これは、UI がコア プロジェクトの Customer クラスへの参照を持っていることを意味します。私のUIはその後、そのCustomerオブジェクトを使用して何かを行い、名前を変更するなどして、最終的にアダプターを再度呼び出してupdateCustomer(customer)を呼び出します。

これは大丈夫ですか？UI がアプリケーション コア内から Customer クラスを使用しても問題ありませんか。または、代わりに Customer を UICustomer などの新しい Customer オブジェクトに適応させ、代わりに UI をそれで動作させ、アダプター レベルで Customer と UICustomer の間を行き来する必要がありますか?

UserServiceコンストラクターには、 aIUnitOfWorkと aの2 つのパラメーターがありIUserRepositoryます。

の複数のインスタンスを区別するために名前付き登録を使用しているため、Unity コンテナーに をIUnitOfWork登録するときは、UserServiceを使用してパラメーターを明示的に指定する必要がありますInjectionConstructor。

new ResolvedParameter<IUserRepository>()省略可能ですか？名前付き登録は必要ないので、Unity に暗黙的にこのパラメーターを推測してもらいたいと思います。 コードは次のようになります。

を使用する必要がない場合はいつでも、これが行われますInjectionConstructor。

ドメイン駆動設計の文献では、ドメイン サービスはステートレスであるべきだとよく言われます。

これは、サービス コールが単一の作業単位を表す必要があるためだと思います。複数のサービス メソッドが使用するサービス状態があってはなりません。

サービスに必要なすべての関連リポジトリをコンストラクターで挿入できるように、サービス アーキテクチャでこの規則を破ります。例：

でコンストラクター注入を使用するにはUserService、サービス メソッドが関連するリポジトリなどにアクセスできるように、状態 (プロパティ) が必要です。

個々のサービス メソッドを独立した作業単位として設計したいと考えていますが、必ずしもそれを防ぐことはできません。

ステートレスになるようにドメイン サービスを構築するにはどうすればよいでしょうか。 これも必要ですか？

編集：

Eric EvansのDomain-driven Design: Tackling Complexity in the Heart of Software :

ドメイン内の重要なプロセスまたは変換が ENTITY または VALUE OBJECT の自然な責任ではない場合、サービスとして宣言されたスタンドアロン インターフェイスとしてモデルに操作を追加します。モデルの言語に関してインターフェースを定義し、操作名が UBIQUITOUS LANGUAGE の一部であることを確認します。SERVICE を ステートレスにします。

また、 Vaughn Vernonは著書「Implementing Domain Driven Design 」でステートレス サービスを推奨しています。

より多くの産業または自動化関連のアプリケーション (管理しなければならない外部コンポーネントに大きく依存しているアプリケーション) では、実際の問題からの抽象化だけでなく、表現も含むモデルがドメインに含まれている場合がよくあります。ドメインの外に物理的に存在するものへのポインター。

たとえば、ネットワーク デバイスを表す次のドメイン エンティティを考えてみましょう。

そのようなエンティティを保存または検証したり、エンティティの変更時にアクションを実行したりするだけでなく、アプリケーションは、ドメイン内の表現に基づいて外部コンポーネントを管理する必要がある場合があります。では、DDD はそのような場合にも適しているのでしょうか? それらのマネージャはドメイン サービスですか?

Eric Evans は有名なブルー ブックで、ドメイン サービスは、エンティティまたはリポジトリが単独では処理できない要求を満たすために、ユビキトス言語から取得したメソッドを実装するステートレス モデルである必要があると説明しています。しかし、サービスがステートフルである必要がある場合はどうでしょうか?

簡単な例: アプリケーションは、状態イベントについてドメイン内の他のアプリケーションに通知するために、ネットワーク内の構成された IP デバイスを監視する必要があります。IP デバイスがアプリケーション内に登録されると (たとえば、データベース内に保存されます)、「ping サービス」が通知され、デバイスの監視を開始します。

次に、他のコンポーネントがこれらのステータス イベントを処理し、たとえば、デバイスがオフラインになると、他のプロトコルを介したデバイスとの通信を停止できます。

さて、それらのコンポーネントは何ですか？最初は、ドメインの特定の要件を満たすため、ドメイン サービスだと思っていました。ただし、これらはステートフルであり、ユビキトス言語を具体的に表していません( ping サービスのタスクは、ドメイン エンティティにpingを実行し、その状態を報告することですが、 ping サービスは、クライアントが ping を許可するメソッドを実装していません)。デバイス）。

それらはアプリケーション サービスですか。そのようなコンポーネントは DDD パターンのどこに収まりますか?