DDDのレイヤー間の通信

DDDの文献を読んで、次のレイヤーを思いつきました。

• Application アウトサイダーワールド（コントローラ、クローンなど）
• Application Services（またはUseCases）-複数のドメインサービスまたはインフラストラクチャサービスを調整します。それらはから呼び出されOutside Worldます。彼らは何をしなければならないか知っています
• Domain Services -物事がどのように行われるかが含まれています（リポジトリインターフェイスに依存）

質問：レイヤー間で通信するためのベストプラクティスはありますか？

私が知っていること：- Application services公開する「必要なデータ」とトランザクションの「成功」の一部（警告、エラー、情報）をApplication Service返す必要があります- 返すデータは、そこから収集しDomain ServicesたりInfrastructure Services、収集したりする必要があります。

Controller <-> Application Service <-> Domain Service          
                                   <-> Infrastructure Service

これらは私の曖昧な考えの一部です：

• すべてのメソッドにApplication Serviceは、「リクエスト」をパラメータとして含む特定のDTOが必要ですか？同様にAddItemToCardCommandDto（必要なすべてのデータをカプセル化していること）。and やorのResultObjectようなメソッドが2つしかないジェネリックはどうですか？getResulthasErrorrsgetMessages

• DomainServiceデータとエラーをどのように返す必要がありますか？例外でエラーを返す必要がありますか？Bussines Validation DomainServicesはビジネスルールの一部であるため、呼び出す必要があるため、これは奇妙に思われます。

DTOを使用すると、モデルの設計が薄れると思います。モデルをリファクタリングし、リファクタリングされたモデルオブジェクトを使用するようにAPIを設計することで、DTOを使用しなくても済むようになります。

クエリ1への回答：application-serviceには、署名付きのメソッドを含めることができます

void addItemToCard(Item item, Card card);

メソッドには、実行しようとしている操作の種類と、レイヤー間で転送するデータに基づいて、戻り値の型とそうでない型があります。各レイヤーに指定されたインターフェースがあり、異なるレイヤーがアプリケーションのすべてのコンポーネントのそのインターフェースを介して互いに通信することを確認する必要があります。

例えば：

List<Items> getItemsOnCard(String cardID);
//returns list of items or empty list if no item can be found.

List<Offers> getOffersApplicableOnCardForItem()
//should return list of Offers or empty list if no item can be found. Should not return a null if no items can be found

すべてのメソッドが同じ動作に準拠していることを確認することは、インターフェースをそのままに保つ上でより重要です。

質問2の回答：

私がそれを正しく覚えているなら、DDDは3つの層を持つことを推奨すると思います。アプリケーション層にドメインインテリジェンスがあると、アプリケーションがドメインにバインドされ、コンテキストが制限されていることがわかります。3では不十分だと思われる場合は、レイヤーを追加することができます。例外を使用して、レイヤー間で情報をカスケードできます。データは、ビジネスのカスタム例外のプレースホルダー内に含めることができます。

これがあなたが持っているいくつかの質問に答えることを願っています。