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

В данном случае я имел в виду исключительно развесистость моделей данных, не другие аспекты. Мы ж про применимость orm говорили.

Так я про то, что модели данных там тоже простые. Но их легко сделать сложными, если не думать.

То есть если на каждый тип сделок заводить отдельный набор таблиц - то конечно все будет грустно.
Но зачем так делать )

Оно там тоже есть,клиенты, выгодоприобретатели, KYC с комплаенсом, всякая бухгалтерия, платежи разных типов, комиссионные схемы, чеки, резервы, контракты, премии, агенты, сервисы, перестрахование,  продукты, отчетность  и т.д. и т.п. и все сильно связано. Очень много всякого реализуется из за требований регуляторов. У меня таки ощущение, что сущностей сильно больше чем в платежных системах. Но это на уровне ощущений опять же, можно померить )

Ну, чтобы померить, нужно внутрь нырять.
А то я видел платежные системы, где ввод, вывод, p2p и p2m были разными сущностями )

Не знаю, как они там в страховании справляются, а в ритейле все усугубляется умножением кол-ва данных (операций в день) на ширину ассортимента. Теперь разговор не про три-пять валют, а про сотни и тысячи строк потоварной раскладки в каждой операции. Если все это сложить в одну универсальную кучу (некоторые пробовали) - оно перестает шевелиться. Производительность приемлемая получается, только если недалеко отходить от нормальных форм и таки да, раскладывать разные объекты в разные таблички, со своими индексами, настроенными под статистики именно этих объектов. Впрочем, надо признать, мой опыт из времен до массового пришествия NoSQL, может сейчас это удалось бы как-то более оптимально разложить по специализированным БД. Хз как, но может быть, может быть....

Хм, а зачем для каждого товара своя таблица, в чем смысл?
Почему не сериализовать каждый товар в какой-то java object, там же все равно поиск идет (внутри операции) по каким-то ключам.
А для поиска на сайте по ассортименту - там уже вообще elastic нужен или что-то специализированное.
Тогда и получается, что реально там - те же пользователи, операции, товары, где-то десяток сущностей на все.
Я делал универсальный маркетплейс, еще и под приличную нагрузку - там мало совсем таблиц получалось )

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

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

Ну да, это есть такое. Но я делал MRP и примерно представляю внутри ERP. Там сложности скорее от модели разработки, нежели от предметной области. Ну и многое проектировалось в 90х, что тоже добавляет тонкостей.

Для каждого SKU. И я видел такие решения, да )

Ну это сюр... и сколько же там было sku? Это наверное, очень маленьких магазин.

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

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

Да, не исключено.

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

Это очень маленькая сетка. Миллион sku - большая.

Вот что точно в тех проектах было плохо - было недорезано по поддоменам Ddd.

Но если уходить от монолита, то получается пачка довольно независимых сервисов, и у каждого - совсем простая БД.
И по доменам даже сложные решения - вполне делятся (да даже в ERP между разными кусками довольно мало связей).
И тогда для каждого сервиса отдельно - уже не нужен ORM, так как там все просто и очевидно.