Доброе утро. Подскажите плиз, пытаюсь разедить систему на агрегаты. Но

выходит фигня, я пытаюсь понять нужно ли оно вообще тут и несет ли вообще бонусы. Или может быть я вообще не правильно их выделяю.

Эта часть не коллаборативная. Те конкуренция на изменения данных низкая.
Вот простой пример с инвариантами:
Есть пользователь
Есть банковские карты
Есть платформы к которым можно привязать банковскую карту
У пользователя не может быть больше 5 платформ
У каждой существующей платформы должна быть привязана банк карта
Если банк карта привязана к какой-то платформе - то она должна существовать

Далее кейсы:
Добавляем новую платформу.
Меняем привязанную банк карту у платформы
Добавляем банк карту
Удаляем саму банк карту

Проблема такая:
Получается что для таких простых инвариантов мне нужно в один агрегат сложить слишком много всего. Либо менять 2 агрегата в одном кейсе. Вот пример:

UserPlatforms
userId
[platformId]


UserCards
userId
[(platformId, selectedCardId)]
[cardId]

Получается когда мы меняем привязанную карту у платформы - мы можем поменять только UserCards проверив, что такая карта существует. При удалении карты мы можем проверить, что ни у какой платформы нет привязанной этой карты - тоже затронув только UserCards.
А вот чтобы добавить новую платформу - нам прийдется тогда затронуть два агрегата UserPlatforms, чтобы чекнуть ограничение в 5 платформ и UserCards, чтобы добавить туда id платформы и привязанную к ней банк карту. Ну и при добавлении новой карты тоже по сути прийдется менять минимум два агрегата


И подобная связанность инвариантами почти со всеми данными внутри модуля. В основном требуется поменять несколько агрегатов за раз при добавлении чего-то нового. Я не правильно моделирую агрегаты? Или это всегда trade-off между eventual и atomic, те прийдется где-то eventual заюзать?
И имеет ли в моем случае с почти отсутствующей коллаборативностью вообще заморачиваться с этим, несут ли агрегаты пользу, если конкурентность за эти данные низкая? Мб просто повесить optimistic lock на userId для исключения рейсов и манипулировать сущностями внутри - как хочется?

> И так, берем за основу какое-то базовое понятие, например, товар, и вокруг него начинаем обобщать. Создаем папку Product. Самый быстрый способ породить кучу god objects это проектировать границы модулей используя большие бизнес сущности. Так у тебя у модулей в лучшем случае logical cohesion выходит, что будет увеличивать каплинг. > Так, по мере необходимости, можно будет выделять компоненты. Обозначим некоторые особенности компонента. не оч понятно "как" именно ты выделяешь компоненты. Если как я предполагаю выше на основе "бизнес сущностей" - это все потом будет очень быстро превращаться в неподдерживаемую шляпу. Плавали там. > Entity отображают таблицы, можно работать с ними, как с простыми структурами, DTO. ясно понятно

Почему бойлерпрейт?

ну то есть то что это процедурщина ты признаешь

чтобы описать процедуру приходится писать класс, а в нем метод + описывать в DI как создавать объект этого класса. И все ради того, чтобы использовать статичную процедуру, без полиморфизма, late binding и вот этого всего

Да не важно процедурщина это или нет

скажем так, я не оч понимаю в чем смысл этой заметки. Выглядит как такое очень наивное поползновение в package by feature но выходит больше package by entity и это приедет к очень большой связанности

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

написать тебе статью ответ где объясняется в чем суть заблуждений?))

Там не было про сущность написано, сущность взята для примера