title: translating specifications into query predicates
body: <p>I'm trying to find a nice and elegant way to query database content based on DDD "specifications".</p>
  
  <p>In domain driven design, a specification is used to check if some object, also known as the candidate, is compliant to a (domain specific) requirement. For example, the specification 'IsTaskDone' goes like:</p>
  
  <pre><code>class IsTaskDone extends Specification&lt;Task&gt; {
   boolean isSatisfiedBy(Task candidate) {
    return candidate.isDone();
   }
  }
  </code></pre>
  
  <p>The above specification can be used for many purposes, e.g. it can be used to validate if a task has been completed, or to filter all completed tasks from a collection. <strong>However, I want to re-use this, nice, domain related specification to query on the database.</strong></p>
  
  <p>Of course, the easiest solution would be to retrieve all entities of our desired type from the database, and filter that list in-memory by looping and removing non-matching entities. But clearly that would not be optimal for performance, especially when the entity count in our db increases.</p>
  
  <p><em>Proposal</em></p>
  
  <p>So my idea is to create a 'ConversionManager' that translates my specification into a persistence technique specific criteria, think of the JPA predicate class. The services looks as follows:</p>
  
  <pre><code>public interface JpaSpecificationConversionManager {
   &lt;T&gt; Predicate getPredicateFor(Specification&lt;T&gt; specification, Root&lt;T&gt; root, CriteriaQuery&lt;?&gt; cq, CriteriaBuilder cb);
   JpaSpecificationConversionManager registerConverter(JpaSpecificationConverter&lt;?, ?&gt; converter);
  }
  </code></pre>
  
  <p>By using our manager, the users can register their own conversion logic, isolating the domain related specification from persistence specific logic. To minimize the configuration of our manager, I want to use annotations on my converter classes, allowing the manager to automatically register those converters.</p>
  
  <p>JPA repository implementations could then use my manager, via dependency injection, to offer a find by specification method. Providing a find by specification should drastically reduce the number of methods on our repository interface.</p>
  
  <p>In theory, this all sounds decent, but I feel like I'm missing something critical. What do you guys think of my proposal, does it comply to the DDD way of thinking? Or is there already a framework that does something identical to what I just described?</p>