6

ドメイン駆動設計では、ドメイン サービスには、本来はエンティティ内に属さない操作を含める必要があります。

エンティティごとに 1 つのサービスを作成し、その中にいくつかのメソッド (OrganizationエンティティとOrganizationServiceサービス)をグループ化する習慣がありました。

しかし、考えれば考えるほどOrganizationService、「組織」はサービスではなく、物です。

そのため、現在、組織全体を複製する組織のディープ コピー機能を追加する必要があるため、それをサービスに入れたいと考えています。

すべきこと: OrganizationService::copyOrganization(o)?

または、次のことを行う必要がありますOrganizationCopyService::copyOrganization(o)。

より一般的には、「サービス」はいくつかの操作を含む抽象的な概念ですか、それともサービスは具体的な操作ですか?

編集：最初のものはそれほど良くなかったので、より多くの例：

  • StrategyService::apply()/cancel()またはStrategyApplicationService::apply()/cancel()？(ここでの「アプリケーション」はアプリケーション層とは関係ありません;)
  • CarService::wash()またはCarWashingService::wash()？

これらすべての例で、最も具体的なサービス名が最も適切と思われます。やはり、実生活では「洗車サー​​ビス」というのは理にかなっています。でも、サービスがいっぱいになってしまうかも…。

※注：これは意見を求める質問ではありません！これは、ドメイン駆動設計の方法論に関する正確で回答可能な質問です。「私はすべきか」と尋ねるとき、私はいつも僅差の投票にうんざりしていますが、物事を行うための DDD の方法があります。

4

2 に答える 2

5

ドメイン サービスのメソッドが 1 つだけであればよいと思います。しかし、ドメインサービスなどで複数のメソッドを持ってはならないというルールではないと思います。インターフェイスが 1 つのことまたは 1 つの動作のみを抽象化する場合、維持するのは確かに簡単ですが、ドメイン サービスの粒度は完全に境界付けられたコンテキストに依存します。低結合性に注目しすぎて、高凝集性を無視することがあります。

于 2013-07-19T14:50:49.043 に答える
1

これは少し意見に基づいているので、コメントとして追加したかったのですが、スペースが足りませんでした。

この場合、メソッドを異なる構築メソッドを持つ個別の OrganizationFactory サービスにグループ化することが理にかなっていると思います。

   interface OrganizationFactory{
       Organization createOrganization();
       Organization createOrganizationCopy(Organization organization);
   }

情報エキスパートのパターンとDRYの原則に従っていると思います.1 つのクラスには特定のオブジェクトの作成に関するすべての情報が含まれており、このロジックを別の場所で繰り返す理由はありません。

それにもかかわらず、興味深いのは、ファクトリ パターンの ddd 定義で

複雑なオブジェクトと AGGREGATES のインスタンスを作成する責任を別のオブジェクトに移します。それ自体はドメイン モデルでは責任を負わないかもしれませんが、ドメイン設計の一部です。すべての複雑なアセンブリをカプセル化し、クライアントがインスタンス化されるオブジェクトの具体的なクラスを参照する必要がないインターフェイスを提供します。

「オブジェクト」という言葉は一般的な意味で、個別のクラスである必要さえありませんが、ファクトリメソッドにすることもできます（クラスのメソッドとパターンファクトリメソッドの両方を意味します）-後でエヴァンスはのBrokerage Accountインスタンスを作成するのファクトリ メソッドTrade Order。

この本は GoF ファクトリ パターンのファミリを参照しており、ファクトリ分解の特別な DDD 方法があるとは思いません。主なポイントは、作成されたオブジェクトが中途半端ではなく、ファクトリ メソッドが追加する依存関係をできるだけ少なくする必要があるということです。 .

update DDD は特定のプログラミング パラダイムに関連付けられていませんが、問題はオブジェクト指向の分解に関するものであるため、DDD がオブジェクトごとのメソッド数に関する特別な推奨事項を提供できるとは思いません。

一部の人々は奇妙な経験則を使用していますが、私は、高結束の原則に従って、関連性の高い責任を持つメソッドをまとめることができると信じています。これは DDD に関する質問なので、ドメイン サービス (つまり、インフラストラクチャ サービスではない) に関するものだと思います。サービスは、ドメイン内での責任に応じて分割する必要があると思います。

update 2 とにかくCarServiceできるCarService::wash()/ CarService::repaint()/CarService::diagnoseAirConditioningProblems()しかし、それができるのは奇妙だろCarWashingServiceうCarWashingService::diagnoseAirConditioningProblems(). チョムスキーの生成文法のように-言語のいくつかのステートメント(文)は意味を成し、いくつかは意味をなさない. しかし、あなたの文に主語が多すぎると (たとえば 5 ～ 7 以上)、たとえそれが言語的に有効な文であっても、理解するのが難しくなります。

于 2013-07-19T13:45:03.260 に答える