ну то есть... нет особо смысла делать профиль юзера как стрим ивентов... нам там может понадобиться лог ивентов для аудита скажем но это не то же самое.

Я кста тут с вопросецом. Вполне же может быть в рамках Контекста несколько агрегатов, которые связаны не по Id, а явной ссылкой(ORM маппит). Если это агрегаты, которые стабильно будут лежать в одной БД и ES там точно не нужен, для банальных CRUD операций. И правильно ли их называть в таком случае AggregateRoot?

aggregate root он один. Их не может быть много. Ну то есть ты не можешь в одной операции для одного и того же агрегата разные руты иметь. Весь смысл теряется.

смысл агрегата - изоляция стэйта и гарантии консистентности стэйта этого агрегата. Для этого стэйт агрегата должен быть в памяти процесса который его меняет и тогда можно чет гарантировать. Если у тебя две штуки берут один и тот же агрегат и один так меняет другой по другому и потом оно как-то само разруливается - просто не используй понятие агрегат. У тебя просто сущности

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

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

Прост у меня что-то вроде:
Есть User. Он может обладать ролями. И в зависимости от Ролей может иметь свой набор конкретных атрибутов. Если пользователь получает роль Driver, то необходимость создать сущность Driver и связать с пользователем. Если роль Client, то создать сущность  Client и связать с пользователем. Пользователь может быть и Driver, и Client. Поэтому наследование не подойдет(тк множественное динамическое). Инвариант: добавление роли должно повлечь создание связанной сущности. Ну и добавление ролей также инкапсулировано в протоколах becomeDriver и becomeClient.

Проблема в том, что как только появляются Driver или Client с ними хочется в CRUD без привязки к User, тк у них уже свои инварианты.

Говоря CRUD я не подразумеваю get/set.

Думаю тут однозначно круд, прочему нет, излишняя сложность никому не помогала

А crud на каком уровне? В репозитории или на контроллере?

Ну и по неймингу для вас это Entity или AggregateRoot? В целом не вижу проблем писать Entity(он ведь не запрещает сохранять инварианты). Тем более AggregateRoot может быть частным случаем Entity. Но выше читал, что Рут это про границы транзакционности и инварианты, а не про то как называть «папочку» в которой что-то лежит.

Интерактор. User user; user.becomeDriver(); repo.add(user);

Если driver и clinet нужно обновлять я бы вынес каждый в отдельный уютный модуль, если не нужно то можно при обновлении действовать по тактике СУБД, удалил, вставил все заного

Как я понял (может ничего не понял) вся история с агрегатами хорошо объяснена

Тут

С его конкретно всё норм, веселье в том что против жсон апи на запись он при этом не выступал, по крайней мере пока

10x понял;)

По риторике вижу что вас в нём что-то не устраивает, но всё ещё не вижу что

Ну я выше там чутка описал чего происходит