Одно из предложений было - начать версионировать файлы с логикой через наследование типа ServiceV2, и создание контроллеров под версии.  Но мне чет не очень

Тогда пока тебе это точно не нужно - не делай версионирование.

Работай с обратной совметимостью и постепенно вноси изменения.

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

Ну грубо говоря, простой пример.

У тебя есть папочка "api/controllers".
делаешь
"api/controllers/v1"
"api/controllers/v2"

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

Замораживаешь старые контроллеры. На это пофиг так как в них кода-то почти не остаётся.

Получаешь версионность апишки, разные форматы команд плюс единую БЛ под любые версии. И возможность быстро плодить версии, а также выборочно их депрекейтить.

Да с контроллерами все просто. Весь вопрос в версионировании логики.

Не версионируй логику.

Тебе апи нужно версионировать, а не логику. Версионировать логику, это тупик.

У тебя что за система по апи общается?

Просто бэкенд для мобильного приложения либо сайта?

Вот, посмотри как и зачем отделять представление от бизнес-логики, Дмитрий Елисеев всё по полочкам разложил )

https://www.youtube.com/watch?v=eU4ajVB9Lz4

Смотрел

Просто тогда появляется if много. Потом забудеш для чего они и зачем. Банально в новой api появилось обязательное поле. Но что с ним делать в БЛ ? Или такого не может быть?

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

Смотря что называть моделью )

Если модель это объекты Active Record (ActiveRecord в Yii2 либо Eloquent Model в Laravel), то предпочитаю в них ничего не держать кроме записи и чтения.

Всю бизнес-логику раскидываю по другим классам: сервисам, хелперам, командам, запросам, валидаторам, иногда делаю Value Object, иногда самостоятельные классы моделирующие часть бизнес-логики. По ситуации, в общем )

Зачем с ним что-то делать в БЛ?

Обязательность поля это уровень валидации запроса, до отправки в БЛ. Это разруливается на уровне апи.

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

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

Вот я об этом и говорю, что в бл появляются всякие if которые могли бы там не быть. Т.е. у нас БЛ для одной версии работает так, а для другой так, для третьей еще иначе. И у нас вместо лаконичного метода начинается вакханалия с проверкой и возможными результатами

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

Нет, не будет. БЛ у тебя будет работать одинаково. Проверка обязательности будет в апи, а не в БЛ.

Давай более конкретный кейс. Приведи пример где пойдёт расхождение в БЛ из-за разных версий апи.

Только реалистичный, а не абстрактный.

может быть такое, что БЛ меняется так, что требуется новвая версия АПИ
но в таком случае старые апи не то что депрекейтятся, они вообще отключаются если без этих данных не может работать БЛ