7

ドメインロジックはドメインオブジェクトに配置する必要があることを私は知っています。しかし、ドメインロジックがデータベースからのデータを必要とする場合はどうなりますか？（たとえば、一意の値、計算された値などをチェックする）ドメインオブジェクトにリポジトリを挿入することは正しいことではないと思います。また、サービスレイヤーにビジネスルールを含めることはできません。では、この種のビジネスロジックをどのように解決するのでしょうか。

4

2 に答える 2

3

ドメインオブジェクトがデータベースから直接データを読み取るべきではないのは正しいです。ここでの古典的なエラーは、ドメイン オブジェクトが Web サービスを介して送信され、データベースにアクセスできないサーバー上にある場合に、データベースからデータを読み取ろうとすることです。

これを行うにはいくつかの方法があります。

  • サービス層は、ドメイン オブジェクトが必要とする情報をプリロードします。
  • ドメイン オブジェクトは、データベースからデータを取得するヘルパーまたはリポジトリを呼び出すことができます
于 2011-05-15T19:14:57.603 に答える
1

私は常に、サービス層がこの種の活動を呼び出すための論理的な場所であることを発見しましたが、後で説明するように、それ自体は私が実装した場所ではありません。サービス層はドメインへのゲートウェイであるため、このデータの必要性を開始する要求が何であれ、そこに到達するにはこのポイントを通過する必要があります。

さらに、サービスを他のサービスと対話させることは非常にクリーンです。これらのサービスは、呼び出しに最小限の労力しか必要としないように特別に設計されているためです。リポジトリで必要な適切な機能 (つまり、Y 基準に一致する X オブジェクトの数を取得できるメソッド / ファインダー / クエリ) を公開し、それを便利なサービス呼び出しにラップできます。これにより、単一のサービス内で簡単にタスクを実行できるようになるだけでなく、より複雑な要件に対してサービス間でこの機能を活用することもできます。

ビジネス ロジックをサービス レイヤーに配置することについての懸念は理解できますが、要件によっては、ビジネス ロジックと実装固有のビジネス ロジックとの間の紙一重です。システムを作成する際に、ビジネス ロジックであると暗示されているが、単に適合しないルールが表面化することがよくあります。一意の制約は、最も一般的な例であることがわかりました。リポジトリ内の他のすべてのものと同様に、これはサービス層での実装ではなく、ドメインに既にあるものの抽象化であることを忘れないでください。

私がしているのは、通常は仕様パターンの実装という形で、「ロジック」自体をドメインに配置することです。ロジックはリポジトリで実行され、サービス レイヤーを変更する必要がないため、これは完全に受け入れられるという結論に達しました。エンティティのコレクションに適用されるルールは、通常「楽しい」ルールであることがわかります。集約ルート内のコレクションで何かが一意であることを確認するだけでよい場合は、それを行うのは簡単です。

I have seen approaches where the domain object has knowledge of the repository, and I am just personally not a fan. The repository, to me, is the definition of how the domain will interface with the persistence layer (although not always the implementation). The fact that an entity even has knowledge that it has a greater purpose than to just exist complicates matters immensely.

于 2011-05-16T13:01:04.813 に答える