サービスはDDDに従ってドメインモデルの一部ですか？私たちが "ddd onion architecture"についてグーグルであれば、最も内側のレイヤーは "ドメインモデルレイヤー"と呼ばれ、2番目のタイプは "ドメインサービス"、例えばhttp://tidyjava.com/onion-architecture-interesting/です。しかし、https://en.wikipedia.org/wiki/Domain-driven_designとDDDの本では、エンティティ、価値オブジェクト、サービスがすべてモデルを表現し、モデル要素であることがわかります。エンティティ、値オブジェクト、およびサービスがすべてドメインモデルの一部である場合、モデル（エンティティ+値オブジェクト）とサービス（私はときどきそうです）の2つのレイヤーをどのように呼び出す必要がありますか？しかし、すべてがドメインモデルの一部である場合、この命名は正確ではないようです。ドメインサービスはドメインモデルの一部ですか？
ドメインサービスはドメインモデルの一部ですか？
はい、
the blue bookには、ドメインサービスが第5章で説明されています。エンティティと値の型の直後。エバンスは書いています
場合によっては、最も明確で実用的なデザインには、概念的にはどのオブジェクトにも属さない操作が含まれることがあります。問題を強制するのではなく、問題空間の自然な輪郭に従い、モデルに明示的にサービスを含めることができます。
サービスは、モデル内に単独で存在するインターフェイスとして提供され、状態....
インターフェイスは、ドメインモデルの他の要素によって定義されます。
しかし、それは常にドメインサービスの実装は、ドメインモデル自体の中に住んでいる場合ではありません。
場合によっては、ドメインサービスが実際にサービスプロバイダとして機能しているため、インフラストラクチャに接続して役割を実行する必要があります（別のプロセスにメッセージを送信するなど）。したがって、ドメインモデルはプロバイダーインターフェイスを定義し、そのインターフェイスの実装が（たとえば、集約ルート上のメソッドへの引数として）渡され、モデルはそのインターフェイスでメソッドを呼び出すかどうかを決定します。
エンティティおよび値オブジェクトは、ドメインサービスのインターフェイスにコンパイル時に依存する可能性がありますか？それらはドメインモデルの同じレイヤー（ドメインサービスのエンティティ、値オブジェクト、インターフェイス）ですか？
はい、はいです。例えば、ここでは7章
今public interface RoutingService {
List<Itinerary> fetchRoutesForSpecification(RouteSpecification routeSpecification);
}
から出荷アプリケーションのan online sampleだ、この特定のデモでは、モデルとは別の名前空間にドメインサービスを維持するために起こる、とapplication service to bridge the twoを使用しています。
return routingService.fetchRoutesForSpecification(cargo.routeSpecification());
しかし、あなたができるように心配する必要はありませんので、
return cargo.fetchRoutes(routingService);
クエリは、あなたにプレイする部屋のビットを与えるモデルの責任のこの部分を作るためにも同様に正しいだろうそれ自身の不変量を保護するモデル。後者のアプローチは、より良いカプセル化を提供するコマンドを使用すると、
order.updateSalesTax(taxCalculatorService);
はDDDによるドメインモデルの一部のサービスはありますか？
ドメイン層の一部です。ドメインサービスは、値オブジェクトまたはエンティティとして自然にモデル化できないドメインロジックをカプセル化します。
タマネギのアーキテクチャでは、すべての依存関係が内側に向いています。値オブジェクトとエンティティは、ドメインサービスに依存してはいけません。ドメインサービスは、エンティティと値オブジェクトに依存します。アーキテクチャの中心には、ドメイン層（value + entities + services）があります。これはビジネス/問題ドメインの抽象ビューであるDDDです。この層は、データベース、Webサービス呼び出し、smtpなどのインフラ関連サービスには依存しません。
上記の1つのレイヤーは、ドメインレイヤーに依存するアプリケーションレイヤーです。アプリケーション層は、ビジネスユースケースを調整するアプリケーションロジックを含むアプリケーションサービスで構成されます。
次のレイヤは、情報、ロギング、セキュリティ、通知、および他の限定されたコンテキストとの統合を格納する技術的実装を担当できるインフラストラクチャレイヤです。このレイヤーによって、Webサービスまたはメッセージエンドポイント経由でアプリケーションレイヤーを使用することもできます。
これらのレイヤー間の密結合を避けるために、上位レイヤーは下位レイヤーのメッセージタイプに適応する必要があります。これらのレイヤーの間で、データ転送オブジェクト（DTO）を使用して、ドメインオブジェクト（エンティティ）を境界線を超えて渡すことはできません。また、特定のテクノロジ（データベースなど）との緊密な結合を避けるため、レイヤはインターフェイスを介して通信します。
あなたの答えをありがとう。あなたはドメインサービスがドメイン層の一部であると言います。しかし、エンティティと値オブジェクトもドメイン層の一部です。しかし、あなたは、エンティティと値オブジェクトがドメインサービスに依存するべきではないと言います。つまり、ドメインレイヤーは2つのレイヤー（サブレイヤー）で構成されています。 –
はい。私の要点を明確にするために、2つのプロジェクトがあるとします。 Domain.Entitiesには、ドメインエンティティと値オブジェクトが含まれます。他のプロジェクトDomain.Servicesにはドメインロジックが含まれています。 Domain.Servicesプロジェクトは、Domain.Entitiesプロジェクトに依存します。 – alltej
ありがとうございます。エンティティと値オブジェクトの一般的な名前はエンティティです。たぶん、わかりにくい名前が見つかるかもしれませんか？エンティティは値オブジェクトの反対であり、両方のエンティティ（プロジェクト名など）と呼んでいます。 –
はい、私はあなたの答えが好きです。しかし、青い本はこのフレーズに言及していません。しかし、ドメインサービスがドメインモデルの一部である場合、エンティティおよび値オブジェクトはドメインサービスのインターフェイスにコンパイル時に依存する可能性がありますか？それらはドメインモデルの同じレイヤー（ドメインサービスのエンティティ、値オブジェクト、インターフェイス）ですか？ –
最新の編集が役立つかどうか教えてください。 – VoiceOfUnreason