Хотя, даже у меня от этих утверждений разрыв с реальностью начинается, что-то делаешь-делаешь, а оказывается это просто интерфейс к бд=)

На тему "DB-first vs Code-first" столько рассказано, что я не буду тут повторяться)

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

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

И это и называется традиционный подход "DB first" )

Плюсы, минусы, примеры )

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

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

Ладно, я тут типа умные мысли говорю, лижбы не работать =)

потом почитаю, наверное что-то похожее на мое. Но вот когда слово доменное употребляют, меня немного коробит, вообще не всегда понимаю что имеют ввиду под доменностью 😅

😅

одним глазом глянул, буквально за 5 секунд, про first-code ну как можно продумать нормальную бизнес-логику не продумав структуру?

добавил в закладки, может почитаю, для общего развития, спасибо =)

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

1. Ты продумал код и структуру данных. Реализовал. Выяснилось, что это не совсем то.
2. Перепроектировал структуру данных и код. Снова реализовал. Опять не то.
3, +++. ....
N. Успех!

В силу особенностей БД, в итоге либо ты потратил много времени на переделывание структуры данных в БД, либо закостылил и изуродовал её...

Оба варианта, не очень привлекательны для заказчика.

Если же ограничиться кодом, то цикл ускоряется.

1. Написал код
2. Переделал код
3. Переделал код
...
N. Добился нормального кода
N+1. Спроектировал структуру данных, подключил БД.

Например, через написание тестов.

Не знаю, возможно я не дорос, но по-моему, когда нужно именно работать с данными, то очень такое. Особенно такое, когда в процессе окажется что как-то не очень получается или вообще какая-то дичь получается из которой не факт что нужный результат получится сфорганить. Мне проще именно продумать сразу сами данные и примерный ход работы с ними, либо уже обдумывать как лучше бысть с существующими данными. Как не крути, то сводится все в данным, а вообще это один из принципов ООП, данные в рамках объектов рассматриваются😅😅😅😅
Но если нужно какую-то небольшую фичу или там функционал какой-то либы заделать, то можно и моками обойтись, наверное =)

Как говорят одни и те же яйца только сбоку =)

Нет такого принципа в ООП...

"завяжись на БД"