操作が概念的にエンティティまたは値オブジェクトに属していない場合は、動作をオブジェクトに強制するのではなく、ドメインサービスを作成する必要があります。
サービスのインターフェースは、ドメインモデルの他の要素に関して定義する必要があります。つまり、サービスのパラメータと戻り値はドメインオブジェクトである必要があります
a）ドメインサービスがドメインオブジェクトをパラメータおよび戻り値として使用する必要があるのはなぜですか？
b）ドメインオブジェクトをパラメーターおよび戻り値として使用するために、DDDがエンティティおよび値オブジェクトのメソッドも必要としないのはなぜですか？代わりに、なぜこの制約がサービスにのみ課せられるのですか？
ありがとうございました
EULERFX：
1）
これらの制約は両方とも、不変性と機能的なスタイルを促進します
a）2つの制約はどのように不変性を促進しますか？
b）機能的なスタイルとは何ですか？
c）したがって、（forceを使用できるとは限らないため）サービスがドメインオブジェクトをパラメーターおよび戻り値として使用するように強制する必要があります。ただし、そのサービス（つまり、動作）が受け入れ/戻るのはより自然な場合があります。非ドメインオブジェクト？
2）
エンティティと値オブジェクトは、より多くのプリミティブ型を構成して複雑な型を形成し、一部の動作はプリミティブパラメータに依存する場合があります。
それで、ドメインエンティティ/値オブジェクトのある種の固有の特性が原因で、ほとんどの場合、それらの動作（つまり、それらの操作）はプリミティブ型で動作します（つまり、プリミティブ型をパラメーターとして使用します）？はいの場合、ほとんどの場合、この固有の特性はドメインオブジェクトに見られますが、ドメインサービスにはめったに見られませんか？
2回目の更新：
2つの制約はどのように不変性を促進しますか？
ドメインサービスは状態を変更せず、すべての状態変更はパラメーターを介して明示的に行われるという考え方です。
a）それ自体の状態または一部のドメインオブジェクトの状態を変更しませんか？ドメインサービスはステートレスである必要があるので、DOの状態を変更してはならないということですか？言い換えると、サービスは、変更しようとしているDOが引数として渡される（つまり、操作に渡される）ことを確認することにより、不変性を促進しますか？
b）しかし、代わりにサービスによって変更されるDOが引数として渡されない場合、ドメインサービスがこのDOの状態を変更したと言いますか？
c）DOの状態を変更することが悪いことと見なされる理由は、それが明確さを促進しないためです（つまり、サービス操作のシグニチャを見るとすぐにはわかりません。DOは状態を変更します。手術 ）？
d）ドメインサービスが引数として渡されたDOの状態を変更する場合、このDOの状態を変更するために使用する値も引数としてサービスに渡されることが理想的です。はいの場合、それは明快さを促進するためですか、それとも...？
2）引数と同じ型の戻り値がどのように不変性を促進するのかまだわかりませんか？
EULERFX 3
a）
ドメインサービスは、渡されたオブジェクトを変更する代わりに、オブジェクトの新しいインスタンスを返すことにより、状態の変化を回避できます。
言うまでもなく、より多くの観察ですが、なぜそのようなサービスの動作がほとんどのドメインモデルで一般的であるのか、またはドメインをモデル化するときにそのような動作が自然に発生するのか、それとも少し概念に強制する必要があるのかを理解するのは難しいですか？！
b）
はい。ただし、その場合は、ドメインオブジェクトがそれ自体を変更する方がよいでしょう。
そして、DOがそれ自体を変異させる必要がある主な理由は、特定のDOで変異を実行するコードが一箇所に集中しているためです。したがって、このコードを検査する必要がある場合、どこでコードを探すべきかがわかります。