В DDD и CQRS для запросов на чтение, что такое стратегия, которая позволяет использовать интерфейсы и простое тестирование?

Я использую PHP / MySQL …

Я использую интерфейсы для репозиториев на моей команде «команда». Все идет хорошо. Но я зациклился на том, что делать на стороне «запросов» (читайте). Я делаю запросы каждый как отдельные методы, сгруппированные по классам с помощью некоторого общего сходства, которое я нахожу? Или я делаю каждый запрос своим классом? Как мне использовать интерфейсы для проведения тестирования (и более легкую замену позже)?

В некоторых местах я исследовал:

  • Пример github php
  • Попытка найти наилучший развязанный подход к запросам на чтение. Примеры используют C #, к сожалению, и сделать его более сложным для понимания.

Эти растворы свернуты?

    В настоящее время мы используем подход со второй ссылки c # для одного из наших проектов. Если вы хотите использовать какой-то фасад запроса, то это лучший, с которым я столкнулся. Мне больше всего нравится то, что вы создаете объекты запросов и обработчики запросов, а затем общий процессор запросов выполняет работу по передаче объекта правильному обработчику.

    В целом, он работает хорошо, однако мне все еще кажется, что я работаю больше, чем мне нужно. Я не совсем уверен, что эта абстракция запроса дает мне, кроме как иметь больше поддержки. Проверяемость часто является ответом на этот вопрос, но я для одного не выполняю тестовые запросы. Групповое тестирование, на мой взгляд, лучше всего оставить для кода, который может потенциально нарушить / повлиять на другой код. Может ли запрос действительно сломать что-либо, что не сразу проявилось бы при регулярном тестировании? Это либо работает, либо нет.

    Если у вас есть веская причина использовать фасад, я рекомендую группировать запросы, связанные с интерфейсом. Например, «IBillingQueries» и «ICustomerQueries».