2

ドメイン サービスはドメインの概念のみを表す必要があると考えていましたが、ドメイン層インターフェイスの粒度を制御し(ドメインの知識がアプリケーション層に漏れるのを防ぎます)、クライアントをエンティティと値オブジェクトから切り離すためにも使用する必要があるようです。

Eric Evan の DDD 本、pg. 108:

このパターンの説明では、概念をサービスとしてモデル化することの表現力を強調してきましたが、このパターンは、ドメイン層のインターフェースの粒度を制御する手段としても価値があり、クライアントをエンティティと値オブジェクトから切り離すこともできます。

中粒度のステートレス サービスは、単純なインターフェイスの背後にある重要な機能をカプセル化するため、大規模なシステムで簡単に再利用できます。きめ細かいドメイン オブジェクトは、ドメインから、ドメイン オブジェクトの動作が調整されるアプリケーション層への知識の漏えいに寄与する可能性があります。

a)ドメインの概念を表すのではなく、粒度のみを制御するドメイン サービスも導入する場合、ドメインに非ドメインの概念を導入するのではないでしょうか。もしそうなら、それはドメインモデルを傷つけませんか?

b)上位層との通信のほとんどは、中粒度のドメイン オブジェクトを介して行う必要がありますか? したがって、細粒度のドメイン オブジェクトを介して通信が行われるすべてのユース ケースに対して、中粒度のドメイン サービスを導入する必要がありますか?

c) Eric Evan の DDD 本、pg. 108:

コーディング規則により、これらのオブジェクトが単なる SERVICE インターフェイスの配信メカニズムであり、意味のあるドメイン オブジェクトではないことが明確になります。

彼が言及しているコーディング規約は何ですか?

アップデート：

引用文はDomain servicesではなくApplication Servicesを説明していると言っていると思いますか?

私はアプリケーション サービスとその目的を認識していますが、著者はドメイン サービスについて説明していると思います。詳細なドメイン オブジェクトが原因で、アプリケーション層への知識の漏洩が発生する可能性があると警告しているためです。

...エンティティと値オブジェクトからクライアントを切り離すだけでなく。中粒度のステートレス サービスは、単純なインターフェイスの背後にある重要な機能をカプセル化するため、大規模なシステムで簡単に再利用できます。きめ細かいドメイン オブジェクトは、ドメインから、ドメイン オブジェクトの動作が調整されるアプリケーション層への知識の漏えいに寄与する可能 性があります。

また、ドメイン層からアプリケーション層への知識の漏洩を防ぎたい場合、(少なくとも私の論理では)ドメイン層内に「障壁」(すなわち中粒度のサービス) を構築すべきではありませんか?

2 番目の更新:

a)

粒度に関しては、ドメイン サービスはアプリケーション サービスと同様の役割を果たします。

どのようなドメイン サービスについて話しているのですか? 粒度を制御するためだけに作成されたものか...?

b)

IMO、アプリケーションサービスが別のアプリケーション層プロジェクトに存在するか、他のドメインオブジェクトと一緒に存在するかは好みの問題です。

ドメインレイヤー内に存在する場合でも、アプリケーションサービスをサービス（粒度を制御することのみを目的としています）と呼んでいますか？

c)

アプリケーション サービスは、知識の漏洩を防ぐという優れた仕事をしており、ある意味でそれが中心的な仕事です。

しかし、「障壁」(つまり、中粒度のサービス) がアプリケーション層内に存在するため、これは、ドメインの知識がアプリケーション層に漏れることを意味しません(ただし、アプリケーション サービスのおかげではありません)。

d)アプリケーション レイヤーはドメイン レイヤーのクライアントであり、著者は本全体を通して、ドメインの知識がクライアントに漏洩してはならないことを警告していると言えます。アプリケーション層(すなわちアプリケーション サービス) がこの規則の例外であるのはなぜですか?

ありがとう

4

1 に答える 1

2

a) ドメインの概念を表すのではなく、粒度のみを制御するドメイン サービスも導入する場合、非ドメインの概念をドメインに導入するのではないか? もしそうなら、それはドメインモデルを傷つけませんか?

サービスはドメインに新しい動作を導入しませんが、ドメイン以外の概念も導入しません。私はこれらのサービス、具体的にはアプリケーション サービスを、ドメインにカプセル化された役割 (ファサード) を提供するものと考えています。サービスの各メソッドはドメイン ユース ケースを表し、ドメイン オブジェクトに直接委任します。これにより、ドメイン層のクライアントは、リポジトリの調整や集約での適切な動作メソッドの呼び出しについて心配する必要がないため、はるかに簡単になります。代わりに、アプリケーション サービスでメソッドを呼び出します。

b) 上位層との通信のほとんどは、中粒度のドメイン オブジェクトを介して行う必要がありますか? したがって、細粒度のドメイン オブジェクトを介して通信が行われるすべてのユース ケースに対して、中粒度のドメイン サービスを導入する必要がありますか?

外側のレイヤーはアプリケーション サービスを呼び出す必要があり、アプリケーション サービスは集約またはドメイン サービスに委任されます。アプリケーション サービスはドメイン サービスとは異なることに注意してください。アプリケーション サービスは、ドメイン オブジェクトがインターフェイスによって公開されないように、ドメインを完全にカプセル化できます。代わりに、DTO を使用して外側のレイヤーとアプリケーション サービスの間でメッセージをやり取りします。これにより、ドメインの保護に加えて、ドメイン モデル以外のものを利用して、トランザクション スクリプトなどのユース ケースを実装する機会が提供されます。

彼が言及しているコーディング規約は何ですか?

CargoApplicationServiceのように、サービス名に Application が存在することも規則の 1 つです。もう 1 つの規則は、コマンド ハンドラーとしても実装できるアプリケーション サービスを、プロジェクト内のアプリケーションモジュールに配置することです。

編集

この本で説明されているドメインを最新の C# スタイルで実装するGitHubのこのプロジェクトを見てください。

アップデート

粒度に関しては、ドメイン サービスはアプリケーション サービスと同様の役割を果たします。IMO、アプリケーションサービスが別のアプリケーション層プロジェクトに存在するか、他のドメインオブジェクトと一緒に存在するかは好みの問題です。アプリケーション サービスとドメイン オブジェクトの間に追加のバリアを作成すると、不要な抽象化になる可能性があります。アプリケーション サービスは、知識の漏洩を防ぐという優れた仕事をしており、ある意味でそれが中心的な仕事です。

更新 2

a) ドメイン サービス全般について話していました。ドメイン サービスはすべて、エンティティや VO を超えて粒度を高める傾向があるためです。

b) はい、ドメインの概念、つまり、それらを実装するために使用されるドメイン オブジェクトよりも粒度の低いユース ケースを引き続きキャプチャするためです。確かに、アプリケーション サービスにはドメインとほぼ直交する懸念がありますが、それらを異なるレイヤーに配置する理由が常にあるとは限りません。

c) はい。しかし、ドメインの知識をまとめて漏洩することは避けられません。Customer エンティティに対応する Customers という名前のデータベース テーブルがある場合、ドメインの知識がデータベースに漏えいしています。重要なのは、すべてのリークを防ぐことではなく、代わりに、変更を加えるときに特定のレイヤーに分離できるように、凝集領域の周囲に境界を作成することです.

d) アプリケーション サービスは、ドメイン オブジェクトの周囲にファサードを作成し、アプリケーション サービス以外のドメインのクライアントが操作するためのクリーンなインターフェイスを持つように効果的に障壁を確立します。このように、アプリ サービスはドメイン オブジェクトと外側のレイヤーの間に位置するため、「例外」です。

于 2013-05-23T18:50:53.620 に答える