問題：
XML フィードからサード パーティのデータを取得しています。そのデータを取得してエンティティに変換する必要があります。
議論のポイント:
私の質問は、この場合のサービスとリポジトリの使用方法です。したがって、たとえば、フィードからデータをプルするサービスを作成し、そのサービスをリポジトリに注入して、それを使用してデータをプルし、エンティティに変換することができます。しかし、それが正しいアプローチであるかどうかはわかりませんか？
リポジトリには、データを取得してエンティティにマップするロジックを含めることができますが、リポジトリがそのロジックを処理する必要はないと思いますか? それともすべきですか？
DDD の懸念の分離の観点から、これをどのように設計するのが最善でしょうか?
フィードからデータを取得するサービスを作成し、そのサービスをリポジトリに挿入できます。
これはドメインとは関係がないため、DDD ではドメイン サービスとは見なされません。これは純粋に技術インフラストラクチャの問題です。
私の質問は、この場合のサービスとリポジトリの使用方法です。
ここでは、2 つの別々の懸念があるようです。リポジトリは明らかに、境界付けられたコンテキストの観点からデータへのアクセスを提供しますが、XML データとリポジトリの間で追加のデータ操作/変換が行われているに違いありません...
DDD の用語では、これは腐敗防止レイヤーと見なされます。外部データ ソースを制御することはできず、慎重に設計されたドメイン モデルの整合性がこの外部データの形式によって損なわれるのを防ぎたいと考えています。
その目的が明確に定義されている限り、腐敗防止レイヤーをリポジトリに挿入してもかまいません。これは、ドメインとは何の関係もないため、ドメイン サービスとは見なされません。これは、外部データ ソースの性質によって引き起こされる純粋な捏造です。
いいえ。
リポジトリには、永続性の無視を提供することを除いて、ドメイン ロジックを含めるべきではありません。
しかし、リポジトリ自体は、データ エンティティとドメイン エンティティの間であらゆる種類の変換を行うことができます。また、要求されたドメイン エンティティを構築できるように、任意の数のテーブルまたはデータベースを使用することもできます。
サービスはリポジトリに注入されるべきではありませんが、その逆です。
リポジトリがデータベースと密接に結合されていない場合 (ほとんどの実装がそうであるように)、次のようになる可能性があります。
別のアプローチ: データを取得してサービス レイヤーのエンティティに変換し、永続化のためにエンティティをリポジトリに渡します。