DDDでは、ドメインサービスは本質的に単なるファサードパターンやメディエーターパターンですか？
ドメイン駆動設計では、ドメイン層にいくつかの（従来の）サービスを含めることができます。たとえば、ユーザードメインの場合、次のようになります。
- さまざまな方法でUserオブジェクトを構築するUserFactory
- インフラストラクチャレイヤーの永続サービスとの対話を担当するUserRepository
ドメインレイヤーのUserServiceは、これら2つのサービスとインフラストラクチャレイヤーのメディエーターやファサードにすぎませんか、それともそれ以上ですか。
Domain servicesは、そうでないものによって最もよく説明されます。
EntitiesでもAggregate rootsでもないValue objectsではありません- 自然に適合しないドメイン知識を運ぶ1つだけ
EntityまたはoneValue object
Domain serviceの例はSaga/Process managerです。これは、異なるAggregate rootsからの複数のBounded contextsを含む長時間実行プロセスを調整します。
そうは言っても、whatはDomain serviceであり、how実装されていることは2つの直交するものです。
ドメインレイヤーのUserServiceは、これら2つのサービスとインフラストラクチャレイヤーのメディエーターやファサードにすぎませんか、それともそれ以上ですか？
SomeUserRepository（Domain layerで定義されたインターフェースとInfrastructure layerでの具体的な実装で構成される）のようなドメインサービスcanFacadeデザインパターン。他のドメインサービスはそうではありません。
Domain layerが他のレイヤーに依存してはならないという重要なルール（および S.O.L.I.D。 ）を除いて、それらを実装するためのhowに関する難しいルールはありません。
Dependency Inversion の結果、DDDにサービスが表示されます。
「プレーン」な依存関係を使用する場合、ドメインコードはデータベースを呼び出してエンティティ、またはエンティティを作成するファクトリを保存またはクエリし、データベースまたは外部サービスやその他のインフラストラクチャコードに関連付けられます。
しかし、それはドメインコードがどうあるべきかではありません。ドメインコードはインフラストラクチャコードに依存しないようにする必要があります。この依存関係により、テストや、場合によっては再利用が難しくなります。これが、その依存関係を逆にする理由です。インフラストラクチャコードをドメインコードに依存させる。そのためには、抽象化を導入する必要があります。ドメインコードがインフラストラクチャによって実装されることを期待する動作を定義する抽象化。
DDDのサービスはその抽象化です。ほとんどの場合、ドメインコードの場合、これらのサービスはプレーンなインターフェースである必要があります。そして、実装は、これらのインターフェースに依存するインフラストラクチャコード内にある必要があります。