перевод спецификации в предикаты запроса

Question

Я пытаюсь найти хороший и элегантный способ запроса содержимого базы данных на основе «спецификаций» DDD.

В доменном дизайне спецификация используется для проверки того, совместим ли какой-либо объект, также известный как кандидат, с требованием (для конкретного домена). Например, спецификация «IsTaskDone» идет как:

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

Приведенное выше описание может быть использована для многих целей, например, его можно использовать для проверки выполнения задачи или для фильтрации всех завершенных задач из коллекции. Тем не менее, я хочу повторно использовать эту, красивую, связанную с доменом спецификацию для запроса в базе данных.

Конечно, самым простым решением было бы получить все объекты требуемого типа из базы данных и отфильтровать этот список в памяти путем объединения и удаления несовпадающих объектов. Но ясно, что это не было бы оптимальным для производительности, особенно когда число лиц в нашем db увеличивается.

Предложение

Так что моя идея заключается в том, чтобы создать «ConversionManager», который транслирует свою спецификацию в технике, сохранения определенных критерии, подумайте класс предикатов JPA. Услуги выглядят следующим образом:

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

Используя наш менеджер, пользователи могут зарегистрировать свою собственную логику преобразования, изолируя спецификацию домена, связанные с настойчивостью определенной логики. Чтобы свести к минимуму конфигурацию нашего менеджера, я хочу использовать аннотации для своих классов конвертеров, позволяя менеджеру автоматически регистрировать эти конвертеры.

Реализации хранилища JPA могут затем использовать моего менеджера через инъекцию зависимостей, чтобы предложить метод поиска по методу спецификации. Предоставление поиска по спецификации должно значительно сократить количество методов в нашем интерфейсе репозитория.

Теоретически это звучит прилично, но я чувствую, что мне не хватает чего-то критического. Что вы, ребята, думаете о моем предложении, соответствует ли он методу DDD? Или есть уже структура, которая делает что-то идентичное тому, что я только что описал?

Answer 1

В мире .NET, который покрыт LINQ. Я не знаю эквивалента Java.

Answer 2

Hades - это структура репозитория как обертка для JPA. Это DDD дружественный. Он поддерживает DDD Specifications из коробки. Я также предлагаю вам ознакомиться с этой статьей от InfoQ.

Answer 3

Я действительно прочитал эту статью, но спецификации hades требуют, чтобы вы включили логику JPA в свою спецификацию . Спецификации являются специфичными для домена и должны храниться отдельно от любого типа логики устойчивости .

Как насчет аннотаций JPA ...? Считаете ли вы, что ваши объекты домена должны храниться отдельно от аннотаций JPA?

Я думаю, что решение, предоставляемое Hades (которое теперь известно как «spring-data-jpa»), является лучшим решением, чем тот, который представлен в книге Эванса: Эрик Эванс показывает пример, где «Спецификация» называет «репозиторий», который сам называет «Спецификацию»!Я действительно задавался вопросом, как клиентский код будет выполнять только спецификацию, а не использовать репозиторий напрямую. Решение, предоставленное Hades/Spring-data-jpa, является хорошим для меня, это нормально, чтобы JPA в логике домена, потому что JPA предназначен для перехода на уровень домена.

EDIT: Я забыл упомянуть, что Эрик Эванс реализует «двойную отправку», это не глупая циклическая зависимость между спецификацией и репозиторием, но, как упоминалось выше, это не мешает разработчику обойти реализацию спецификации.