Ты путаешь cqs и cqrs + скорее всего ещё шины всякие туда подмешиваешь

Про путанье да, никак не могу понять разницу. CQS- это на резделение команды и чтение, CQRS - на рид и врайт модели?  Но скорее всего не прав.
Про шины - нет.

Cqs про разделение на методы с сайд эффектами (которые меняют состояние) и методы которые не имеют сайд эффектов и только возвращают некий результат запроса (в общем смысле, это на уровне модуля, тоесть можно на примере класса какого типа datetime рассматривать)

Профит - однонаправленный поток данных. Так же как один из вариантов "упрощения" это проще тестить (query - только стабы, command только моки).

Есть всякие array_pop которые жертвуют cqs в угоду атомарности операции

Понятно, спасибо. А почему в командах только моки? Ведь для команд нужны теже репозитории, чтобы сущности забрать. Или это происходит где то извне(снаружи) команды  и она получает готовые данные/сущности?

репозиторий мокается

В cqs команда или query это грубо говоря про методы. Упрощённо - методы которые меняют стэйт - они должны быть void. Отсюда и про моки - команды только мокать

Сложное разделение... спасибо. Чет читал читали  не понял значит.

вам нужно оттестировать как работает команда, только ее код
для этого вы мокаете репу и говорите ей возвращать то или иное значение чтобы проверить как на него будет реагировать ваша команда

Стабится*

Тогда вопрос выше снова открыт)

Мне чтобы стейт изменить - надо сначала его из базы забрать, т.е. застабить репо

не факт, смотря что хотим проверить, не уверен что стабом можно проверить результат некоего вычисления который будет передан в репозиторий, например

Как я понял, стаб - возвращает результат, мок -  проверяет.  Поправьте если не прав.

Повторюсь - в CQS команда это «некий метод» который вызывает сайд эффект и по тому не может ничего возвращать. Что происходит внутри - внутри уже свои зависимости и у них свои методы и какие-то из них команды а какие-то query.

rule of thumb - хочешь ретурн тайп отличный от void то в этом методе не должно быть сайд эффектов

rule of thumb для стабы или моки - если ретурн тайп не void юзай стаб

и то и то может возвращать результаты
стаб это проверка стейта - т.е когда у обьекта вызывается метод vasya то стаб вернет всегда одно и тоже (с вариациями) - т.е вам важно что именно вернет обьект, а будет ли вызван - пофиг
мок - это когда вам важно что тестируемой код вызовет метод vasya обятально, а если нет - то это баг

public function it_does_things(SomeRepo $repo)
{
   $repo->getByRange($correct, $dateRange)->willReturn($whatsNeeded);
   $repo->getByRange(Arguments::cateria())->willReturn(null); // by default

   // do things
}


и не надо проверять вызвал ты или нет. И меньше деталей реализации наружу вылазят. Дальше еще rule of thumb что стабить надо не только то что юзает реализация но всю реализацию интерфейса.

Как если бы ты делал in memory repo.

именно по этому моки есть смысл юзать с void и нет смысла юзать с return type. исключения - вот эти всякие array_pop - там нет однозначности как лучше

то есть метод add в репозитории мы мокаем, а методы типа get стабаем

Все, кажется понял где рассинхрон мыслей. Вы говорили мокать саму команду, а стабить квери. Я же думал про их зависимости. Т.е сама по себе команда может иметь внутри другие команды и квери, а значит и содержать в зависимостях  стабы и моки.

внутри и то и то обычные методы. «трюк» и риазница могут быть только в том что методы query поскольку не могут иметь сайд эффектов не могут дергать «команды»