Я так на это смотрю (и это субъективный подход) :

DB Constraints, field types - это integrity check. Это часть "Data Layer / Storage". Ты гарантируешь что данные типизированы (в широком смыслe). Этим занимается база данных или любой другой Data Source.

Data Access Layer - это Repository Pattern. Здесь ты вытаскиваешь данные из Data Layer в BLL через контракт (behaviour).

Business Logic Layer - здесь бизнес логика. Ей похер где лежат данные. У нее есть котракт с DAL. Я могу выкинуть Ecto и поставить хоть гравицапу. Главное чтобы behaviour был имплементирован.

Где-то на верхушке BLL - Validation Layer - он проверяет все то, что не проверишь на integrity check или не засунешь туда. В несложных случаях integrity check'а хватает.

И завершает все Delivery Layer. Это контроллеры или GraphQL схема. Тут ты тупо тыкаешь DAL.

---

Я работаю в мед-секторе и мы пишем адски конфигурируемый софт. Уровень меты порой зашкаливает. AR реально начинает превращаться в фарш, 5-этажные where разбросаны по всему проекту и дублируются т к более 50 инженеров над этим всем работают.

И еще, с AR ты перемешиваешь DAL и BLL ибо у тебя where прямо внутри логики и так принято.

Кажется, это не имеет никакого смысла. Но даже если так, можно через отдельный сервис это реализовать, скипая нужные валидации

а еще я бы рекомендовал сменить пример - email очень плохой пример для валидации

Ну то есть сначала придумать проблему, а потом героически решить ее

И вот в ту структуру, которую я описал я могу интегрировать что угодно. Православный layering + SOLID vibe

Но она дорогая. Если она не решает проблем - AR может быть достаточно. Мы же юзеров радовать должны, а не поклоняться Мартину Фаулеру))

Вопрос: зачем вообще концептуально блин делить дату и бизнес-логику в целом приложении? Возможно, я не прав, но я на это смотрю с точки зрения того, что практически никогда не возникнет ситуация, когда я захочу поменять DAL или базу данных в конкретном приложении. Зачем? Это всё оправдывается только словами "можно выкинуть А и поставить Б"?

А проблема в чём?))

бизнес-логика ничего не знает об индексах и нормализации/денормализации в бд

Вот примера с where не понял. Почему того же самого не будет в любом другом слое запросов к бд?

Ну так можно на уровне кода это разделить, а не на уровне инструментария

В том, что не всегда нужны одинаковые валидации в разных местах. Классическая ситуация, когда в админке не нужно валидировать что-то

И ради этих 5% случаев писать в 3 раза больше кода всегда. Просто потому что однажды в админке понадобится валидации обойти.

Мне сложно это объяснить кратко. Надо сначала подумать и обобщить, все же NDA. Если отвечать хоть как-то:

Возможен случай когда часть юзера в БД. А потом часть ответсвенности модели выносят в SSO. И тут открывается интересный путь - если бизнес-логика неизменна, то можно просто в DAL все сделать.

Смерджить данные из API и DB

И этим может заниматься отдельная команда.

Профиты начинают быть хорошо видны на enterprise level. Когда 50+ человек на проект и т п. Layering это не только про код. Это и про коммуникацию между командами в разных часовых поясах.

И ради возможности использовать 50+ инженеров эффективно.

50+ не договорятся между собой. Нужны четкие design constraints. Чтобы DRY решалось не на ответственности и знании кода, а на уровне архитектуры.

Допустим. Как это связано с двумя разными паттернами, которые мы обсудили?