0

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

ここに画像の説明を入力

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

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

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

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

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

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

問題

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

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

質問

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

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

4

2 に答える 2

1

電子メールの送信が境界付けられたコンテキストの概念ではない場合、それは別のコンテキストの一部であることを意味します。そのため、ドメイン イベントの腐敗防止レイヤーなど、境界付けられたコンテキストの統合パターンの一部を適用する必要があります。

あなたが何を選んだとしても、あなたの構造と解決策には別の問題があり、それが問題の問題を解決します。オブジェクトのタイプではなく、ユビキタス言語を使用する境界付けられたコンテキストとモジュールの観点からアプリケーションを構築するようにしてください。したがって、インターフェイス、モデル、サービスではなく、製品、クライアント、出荷などを用意する必要があります..

于 2014-01-24T15:19:43.043 に答える