В DDD и CQRS, для запросов на чтение, какова стратегия, которая допускает интерфейсы и простое тестирование?
Я использую PHP / MySQL …
Я использую интерфейсы для репозиториев на моей стороне домена «команда». Это идет хорошо. Но я застрял на том, что делать на стороне «запросов» (чтения). Я делаю запросы каждый как отдельные методы, сгруппированные в классы по некоторому общему сходству? Или я делаю каждый запрос своего класса? Как мне использовать интерфейсы для проведения тестирования (и более легкой замены позже)?
Некоторые места, которые я исследовал:
- Пример github php
- Попытка найти лучший развязанный подход к запросам на стороне чтения. К сожалению, примеры используют C # и делают его более сложным для понимания.
Эти решения запутаны?
Решение
В настоящее время мы используем подход из второй ссылки c # для одного из наших проектов. Если вы хотите использовать какой-либо фасад запроса, то это лучший, который я встречал. Что мне больше всего нравится в этом, так это то, что вы создаете объекты запросов и обработчики запросов, а затем общий обработчик запросов выполняет работу по передаче объекта нужному обработчику.
В целом, это работает хорошо, но мне кажется, что я работаю усерднее, чем нужно. Я не совсем уверен, что дает мне эта абстракция запроса, кроме того, что мне нужно больше поддерживать. Тестируемость часто является ответом на этот вопрос, но я, например, не тестирую запросы. Модульное тестирование, по моему мнению, лучше всего оставить для кода, который потенциально может сломать / повлиять на другой код. Может ли запрос действительно нарушить то, что не было бы сразу видно при регулярном тестировании? Это либо работает, либо нет.
Если у вас есть веская причина использовать фасад, то я рекомендую сгруппировать запросы, связанные с интерфейсом. Такие как «IBillingQueries» и «ICustomerQueries».
Другие решения
Других решений пока нет …