DDDでは、ドメインサービスは基本的にはファサードパターンやメディエーターパターンだけですか？

ドメイン駆動設計では、ドメイン層にいくつかの（従来の）サービスを含めることができます。たとえば、ユーザードメインの場合、次のようになります。

• さまざまな方法でUserオブジェクトを構築するUserFactory
• インフラストラクチャレイヤーの永続サービスとの対話を担当するUserRepository

ドメインレイヤーのUserServiceは、これら2つのサービスとインフラストラクチャレイヤーのメディエーターやファサードにすぎませんか、それともそれ以上ですか？

Domain services それらがそうでないものによって最もよく説明されています

• 彼らはどちらEntitiesでもないAggregate roots
• ではない Value objects
• 自然に1つ Entityまたは1つだけに当てはまらないドメイン知識を運ぶ Value object

aの例Domain serviceは次のSaga/Process managerとおりです。複数のものを含む長期実行プロセスを調整Aggregate rootsしますBounded contexts。

そうは言っても、何でありDomain service、どのように実装されるかは、2つの直交するものです。

ドメインレイヤーのUserServiceは、これら2つのサービスとインフラストラクチャレイヤーのメディエーターやファサードにすぎませんか、それともそれ以上ですか？

いくつかの様ドメインサービスUserRepository（で定義されたインターフェースにより構成されるDomain layerとにおける具体的な実装はInfrastructure layer） ことができる使用して実装することがFacadeデザインパターンを。他のドメインサービスはそうではありません。

他のレイヤー（およびSOLID）に依存してはならないという重要なルールを除いて、それらを実装する方法についてハードルールはDomain layerありません。

依存関係の逆転の結果としてDDDにサービスが表示されます。

「プレーン」な依存関係を使用する場合、ドメインコードはデータベースを呼び出してエンティティ、またはエンティティを作成するファクトリを保存またはクエリし、データベースまたは外部サービスやその他のインフラストラクチャコードに関連付けられます。

しかし、それはドメインコードがどうあるべきかではありません。ドメインコードはインフラストラクチャコードに依存しないようにする必要があります。この依存関係により、テストや、場合によっては再利用が難しくなります。これが、その依存関係を逆にする理由です。インフラストラクチャコードをドメインコードに依存させる。そのためには、抽象化を導入する必要があります。ドメインコードがインフラストラクチャによって実装されることを期待する動作を定義する抽象化。

DDDのサービスはその抽象化です。ほとんどの場合、ドメインコードの場合、これらのサービスはプレーンなインターフェースである必要があります。そして、それらのインターフェースに依存するインフラストラクチャー・コードに実装を含める必要があります。