Например, есть пользователи и у него есть поле Friends, где записаны id друзей. Вопрос валидации этих id

Типы и ещё раз типы

1) Какое отношение имеет язык домена к модели данных? Возможно, это и есть реальная область применимости orm - когда модель данных и доменная модель смешаны? И бизнес-логика напрямую работает с базой (через orm).

Ну да, для большого (и не модульного) монолита без orm  наверное и правда будет тяжело.

В страховании да, очень развесистые. Контракты, продукты,  убытки, премии, комиссии, агентские договора, резервы и еще 100500 сущностей с кучей полей. При этом есть специфика - ежедневный массовый батч процессинг и операционный репортинг в бекофисе, когда все это добро нужно между собой связать по полям и выгрузить агрегированную отчетность, например, где результирующее множество формируется  на основе обьединения десятков и сотен миллионов записей в крупной компании или массово заапдейтить. ORM это ж еще и дополнительные накладные расходы, на обьемах весьма существенные. Сейчас как раз думаю, как кровавый энтерпрайз-монолит страховой, живущий на оракле и хранимках распилить, так чтобы не сломать процессы.

А, так валидация целостности - в любом случае ответственность бэкенда, так что какая разница?

Хм, да не больше же, чем в любой платежной системе? И практически нет значимых внутренних связей.
Все это легко укладывается в 20-30 таблиц с jsonb и без всякого ORM

А откуда в платежной системе много сущностей?

Пользователи (со всем KYC и процессами идентификации), мерчанты, эквайеры, шлюзы, лимиты, отчеты. Сами платежи - как раз самое простое и скучное.

Вот кажется, что немного. Хотя со стороны домен всегда кажется проще.

кешбоксы, леги, транзакции, аккаунты, счета, реквизиты, чеки,

Ну и я бы еще дофига добавил, да )

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

(Видел я разработку ERP, где в среднем один разработчик создавал одну новую таблицу в день - в течении нескольких лет)

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

А откуда в страховании или в ретейле больше сущностей? С ритейлом связывался - там все просто.
Бумекерский домен - тоже просто.

мало кому в жизни удается сделать более 1 платежного решения, при этом как и в любом домене хорошо получатеся на 2-3 раз, кмк

Я сейчас делаю, кажется, четвертое. Или пятое.

Но уже второе было норм )

Деталей и вариантов внутри сделок гораздо больше, и это точка конкуренции.