問題タブ [ddd-service]

私はアーキテクチャが初めてです.MVC Webアプリケーションプロジェクトがあり、EFコードを最初に使用したい.このプロジェクトにアーキテクチャを使用したい.DDD(ドメイン駆動設計)を使用したいが、それは大規模プロジェクト用です. 私のプロジェクトでこれをサポートする単純な DDD が必要です: 1-リポジトリ パターン 2-IOC 3-サービス レイヤー

ドメイン駆動設計を学びながら、次の解決策をまとめました (この順序は辞書順であり、依存関係を表すものではないことに注意してください)。

以下、各プロジェクトの概要です。

Domain.Models: ドメイン エンティティと値オブジェクト (例: Order)

Domain.Interfaces: ドメイン サービス インターフェイスとリポジトリ インターフェイス (例IOrderService: IOrderRepository)

Domain.Services: ドメイン サービス インターフェイスの具体的な実装 (例: OrderService)

Infrastructure.Data: リポジトリ インターフェイスの具体的な実装 (例: OrderRepository)

Infrastructure.DependencyResolution: 依存性注入の解決。

問題

今、私はドメイン以外のサービスを提供したいと考えています。例としては、電子メールを送信するための電子メール ゲートウェイがあります。このために、次のプロジェクトを作成しました。

Infrastructure.Components: 非ドメイン サービスの具体的な実装

質問

このような非ドメイン サービス (たとえば、IEmailGateway) のインターフェイスはどこに配置しますか?

Domain.Servicesプロジェクトからアクセスできる必要があるため(OrderService通知を送信する必要がある場合があります)、Domain.Interfacesに入れますか? メールの送信はドメイン固有のアクティビティではないため、NO と言います。

これらのマップされたオブジェクトを外部の世界に公開する Web サービスで使用する必要があるドメイン層に、マップされたオブジェクト [エンティティ] がいくつかあります。これらのマップされたオブジェクトの正しい場所はどこですか? マップされたオブジェクトをどのように構成し、正しい場所はどこですか?

私のプロジェクトは、エンティティ フレームワーク6 を使用し、次のレイヤーを持つ MVC5 .NET プロジェクトです。

UI + アプリケーション層 ドメイン層 ( Entities.MappedObjects は、今のところマップされたオブジェクトを置く場所です) インフラストラクチャ層 (すべての配管と DB へのアクセスを行います)

DDD Eg で共有値オブジェクトを使用する方法について知る必要がありますか?

Registration と Admissionという 2 つの集約ルートがある場合、両方の集約が Address という値オブジェクトを消費します。私のユビキタス言語は異なりますが (入場アドレスと登録アドレス)、この Address オブジェクトのモデルは同じです (共通のプロパティがあることを意味します)。したがって、この値オブジェクトをこの両方の集計ルートからコンテキスト内の共通の場所に移動することにしました (SharedValuess と言ってください)。このプラクティスが優れていること、またはこの種の状況を処理するために利用できる成熟した方法があることを知りたいです。

注意: この投稿は、回答が意見に基づいているため、スタック オーバーフローのルールに反する可能性がありますが、この質問をするアクティブなフォーラムは他に見つかりませんでした。

ドメイン駆動設計を使用しています。

私は次のモデル（クラス）を持っています：

• ユーザー
• ユーザーDAO
• ユーザーリポジトリ
• ユーザーサービス

UserService には、対応するすべてのアプリケーション ロジックが含まれているはずです。signUp()そこで、 、logIn()などのメソッドを取得update()しました。

私のsignUp()方法では、ユーザーをサインアップしますが、電子メールの UNIQUE 制約に違反した場合に PDO 例外をスローします。さて、例外は例外的なエラーのみであり、制御フローには悪いので、私の質問は次のとおりです。

emailExist()メソッドを UserService クラスに入れることはできますか?

そのため、実際にユーザーをサインアップする前に、最初にコントローラーでそれを呼び出すことができます (そのため、メールが既に存在する場合はフォーム エラーで報告できます)。そのようなメソッドが実際にはデータマッパーに属していることは知っていますが、コントローラーで直接使用することは想定されていないため、 UserService クラスに追加し、そこからリポジトリのfindByEmail()メソッドにマップすることを考えました。

データベースに格納されたデータに依存するビジネス ルールの検証を実装する最善の方法を見つけようとして苦労しています。以下の単純化された例では、Username 属性が一意であることを確認したいと考えています。

私はすでに、リポジトリをエンティティに注入する（そしてそれが無効な状態になるのを防ぐ）、拡張メソッドの作成など、それを達成するためのさまざまな方法について多くのことを読んでいます.

ただし、これらのいずれもそれを行うための最良のアプローチではないと思います。

そこで、アプリケーション サービスを使用して、仕様を使用してエンティティの検証を調整することにしました。

最初は、よさそうだった。しかし、サービスは仕様の実装に密接に結合されており、仕様の依存関係を手動で処理する必要があるため、単体テストはやや困難です。仕様を抽象化することも考えましたが、正しい方法かどうかはわかりません。

実際に私は DDD を学んでいて、この種の検証を担当するレイヤーをまだ明確に考えていないため、私が間違って始めた可能性もあります。

どんな助けでも大歓迎です。

エンティティの ID を使用するか、参照として渡すかを使用できる 2 つのケースがあります。

1) ドメイン サービス。例：

2) エンティティ。例：

どちらのアプローチが優れているか、またその理由は?