Это очень хорошая практика, но сложно следить чтобы однов другое не протекало ) Без специальных ухищрений типа deptrac

ок, application logic vs domain logic

Ну что-то вроде )

Ну вот а если . Я повторюсь "а если", какая либо логика будет в середине. т.е.

send(request){
20 строк кода
if(...)
20 строк кода
}

то будет примерно так:

sendV1($message){
sendHeader($message);
$operator = $this->setting->getOperator();
sendFooter($operator, $message)
}

sendV2($message, $login){
sendHeader($message);
$operator = $this->remoteApi->getOperator($login);
sendFooter($operator, $message)
}
Похоже

на ерунду)

А потом выходит 3 версия, которая другое условие ставит в другом месте и вообще "поехали"

Нет, у тебя будет тот же код что и был. Изменится только метод send, в котором использование уехало в середину. sendV1 и sendV2 никак не изменятся.

Это если только его касается, а потом мы уже в send (точнее из send отпучковываем новый метод) снова что-то выносим в зависимости от 3 версии. Я просто к тому, что это скорее усложнение, чем упрощение одного if

У тебя зависимость не от версии, а от новой бизнес-логики. Если бизнес-логика появилась новая то логично что код растёт. Раньше у тебя был один способ отправить сообщение, стало два.

Это не версионирование апи, это уже просто развитие бизнес-логики, в которую мы что-то добавили и предоставили доступ через новую версию апи. Тут усложнение оправдано.

Другой вопрос, что сложность решения в коде не должна превышать сложность самой бизнес-логики. Добавив 1 новую функциональность и добавив на неё 1 метод, мы всё ещё держим ситуацию под контролем.

Тут момент в том, что если бы не было v1, то у меня в БЛ было required поле в команде для v2. А так - опционально.  Тут конечно да, можно подойти с другой стороны - мы расширяем нашу БЛ. Но лишние условия делают код более хрупким, а тесты более сложными (пфф говорить о тестах и не юзать XD ).

Нет, у тебя оно и так required для V2. Не опционально. Для V1 не используется, для V2 всегда используется и required.

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

Это обеспечивается кодом и IF. Максимум что может его зареквайдить - это первичная валидация в контроллере.

Нет никакого IF. Где ты взял IF? :/

Так в этом то и  соль. Мы V1 рипаем, а легаси остается в виде if  моем случае и виде вынесенного send в твоем - что придает немного сложности в чтении . Плюс надо подчищать именно юзкес будет где был метод sendv1 а не просто папку рипнуть, и так во всех классах.

В случае с контроллером - мы рипаем папку и радуемся. А тут легаси код остается, если его не чистить

А чистка может привести к поломке) ну как обычно )))) понятно что в простом примере все изи, но на деле не так обычно...

Доброго времени суток!

Как вы думаете, прав ли этот коментатор https://github.com/atomastic/registry/issues/4 ?

Разве паттерн реестр - это не синглтон с запертом на наследование ?
как это у меня реализованно сейчас

Какой IF? Где он? Вот код... https://phpsandbox.io/n/raspy-king-k0k4-fbmun

Я же написал if - как я изначально описал, в твоём случае метод send sendv1 которые останутся виде легаси и доп сложности для чтения. при рипе первой версии апи