将规范转换为查询谓词

Question

I'm trying to find a nice and elegant way to query database content based on DDD "specifications".

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:

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

The above specification can be used for many purposes, eg it can be used to validate if a task has been completed, or to filter all completed tasks from a collection. However, I want to re-use this, nice, domain related specification to query on the database.

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.

Proposal

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:

public interface JpaSpecificationConversionManager {
 <T> Predicate getPredicateFor(Specification<T> specification, Root<T> root, CriteriaQuery<?> cq, CriteriaBuilder cb);
 JpaSpecificationConversionManager registerConverter(JpaSpecificationConverter<?, ?> converter);
}

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.

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.

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?

Answer 1

Hades is a Repository framework as a wrapper for JPA. It is DDD friendly. It supports DDD Specifications out of the box. I also suggest you look at this article from InfoQ .

Answer 2

I actually read that article, but hades specifications require you to include JPA logic in your specification. Specifications are domain specific and should be kept separate from any type of persistence logic.

What about JPA annotations man...? Do you think your domain objects should be kept seperate from JPA annotations ?

I think the solution provided by Hades (which is now known as " spring-data-jpa ") is a better solution than the one provided in Evans book : Eric Evans shows an example where a "Specification" calls a "Repository" which itself calls the "Specification" ! I really wondered how client code would only go through the specification, and not use the repository directly. The solution provided by Hades/Spring-data-jpa is a good one to me, it's ok to put JPA in domain logic, because JPA is designed to go in the domain layer.

EDIT : I forgot to mention Eric Evans implements a "double dispatch", it's not a silly circular dependecy between specification and repository, but as mentioned above, it doesn't prevent any developper to bypass the specification implementation.

Answer 3

In the .NET world, that is covered by LINQ . I know of no Java equivalent.