仕様をクエリ述語に翻訳する

Question

私は、DDDの "仕様"に基づいてデータベースの内容を照会するうまいエレガントな方法を見つけようとしています。

ドメイン駆動型設計では、特定のオブジェクト（候補とも呼ばれます）が（ドメイン固有の）要件に準拠しているかどうかを確認するための仕様が使用されます。例えば、仕様「IsTaskDoneは」のように進む：

class IsTaskDone extends Specification<Task> { 
boolean isSatisfiedBy(Task candidate) { 
    return candidate.isDone(); 
} 
} 

上記の明細書は、例えば、多くの目的のために使用することができますタスクが完了したかどうかを検証したり、完了したすべてのタスクをコレクションからフィルタリングしたりするために使用できます。 しかし、この素敵なドメイン関連の仕様を再利用してデータベースのクエリを実行したいと思います。

もちろん、最も簡単な解決策は、データベースから目的のタイプのすべてのエンティティを取得し、一致しないエンティティをループして削除することでそのリストをメモリ内にフィルタすることです。しかし、パフォーマンスが最適ではないことは明らかです。特に、エンティティがdbを増やす場合は特にそうです。

提案

だから私の考えは、JPAの述語クラスを考え、永続化技術、特定の基準に私の仕様を翻訳する「ConversionManager」を作成することです。サービスは次のようになります。

管理者を使用することで、ユーザーは独自の変換ロジックを登録し、ドメイン関連の仕様を永続固有のロジックから分離することができます。私たちのマネージャの設定を最小限に抑えるために、私はコンバータクラスでアノテーションを使い、マネージャがそれらのコンバータを自動的に登録できるようにしたいと思います。

JPAリポジトリの実装では、依存関係インジェクションを使用して自分のマネージャを使用して、検索方法を提供することができます。仕様による検索を提供すると、リポジトリインタフェース上のメソッドの数が大幅に削減されるはずです。

理論的には、これはすべてうまく聞こえますが、私は何か重要なものが欠けているように感じます。あなたは私の提案について何を考えますか、それはDDDの考え方に従っていますか？あるいは、私が今説明したものと全く同じことをするフレームワークがすでに存在していますか？

Answer 1

.NETの世界では、LINQでカバーされています。私はJava同等のことを知っていません。

Answer 2

Hadesは、JPAのラッパーとしてのリポジトリフレームワークです。 DDDフレンドリーです。 DDD Specificationsをそのまま使用できます。私はまた、この記事をInfoQから見ることをお勧めします。

Answer 3

私は実際にその記事を読んでいますが、仕様によっては 仕様にJPAロジックを含める必要があります。仕様はドメイン特有のものであり、任意のタイプの永続ロジックであるとは別に保管する必要があります。

JPAアノテーションはどうですか？ JPAアノテーションからドメインオブジェクトを分離しておく必要があると思いますか？

私はHadesが提供するソリューション（現在は "spring-data-jpa"と呼ばれています）は、Evansの書籍よりも優れたソリューションだと考えています。Eric Evansは、 "Specification"が "Repository" "仕様"と呼んでいます！私は本当にクライアントコードが仕様書をどのように辿り、リポジトリを直接使用しないのか、本当に不思議でした。 Hades/Spring-data-jpaが提供するソリューションは私にとっては良いことですが、JPAはドメイン・レイヤーに入るように設計されているため、JPAをドメイン・ロジックに入れることは大丈夫です。

編集：私はEric Evansが "二重ディスパッチ"を実装していることを忘れていました。仕様とリポジトリの間に奇妙な循環依存関係はありませんが、上記のように開発者が仕様実装をバイパスすることはできません。