Другой вариант сделать так, чтобы какое-то небольшое время система была неконсистента, то есть A уже будет создан, а B ещё нет: после создания A добавлять в фоновую очередь задачу на создание B.

Это же и будет тот самый eventual consistency, да?

Да

Какой путь лучше?

Агрегат TokenEntollment

Если вкратце:
1 запрашивается подтверждение у пользователя
2 обрабатывается ответ
3 в зависимости от результата изменяется состояние

Нашел похожий пример.
Тут по сути те же состояния, только слеплены в 1м классе. Или это норм?

https://github.com/cstettler/ddd-to-the-code-workshop-sample/blob/master/ddd-to-the-code-workshop-registration/src/main/java/com/github/cstettler/dddttc/registration/application/UserRegistrationService.java

it depends. Если это все происходит внутри агрегата то мы не говорим ни о каких ивентах там или чем-нибудь еще. Это просто переход стэйта. Нет ни ошибок ни ивентов.

Если мы говорим про "ивенты" именно, мол "не удалось чет сделать" - то за это отвечают штуки которые часто называют policy. Это может быть просто application level сервис который за координацию действий отвечает. Или процесс менеджер какой. Но это если ивенты именно ивенты.

Если ты ивенты ошибок делаешь используя исключения - то это уже отдельная песня почему строить control flow на исключениях грех

в контексте агрегатов я полагаю речь идет о том что:

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

Это как бы "норм" только если у тебя нет там какой-то логики "если было исключение то надо сделать что-то еще". Но по дефолту лучше воспринимать это как оч вонючий код смел

Да, я про этот случай.
Логика на исключениях не завязана, но обрабатывать приходится.

Ивенты действительно не к чему, просто переход состояния))

Спасибо)

Путей на самом деле больше: 1/ спихнуть все на уровень СУБД 2/ пожертвовать целостностью и 3/ купить/сделать Object Transactional Service

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

есть еще git subtree но там вообще тлен с циклом бэкпорта и иногда глючил при неправильном использовании так, что стирал всё дерево проекта😂

Спасибо за развернутый ответ, с сабмодулями похоже больше проблем чем пользы.

Блин, вот всё норм, но уже задрали. Я их в воду буду кунать! Свои праила. Походу бизнес ничего не знает!

Кругом дибилы

Извините, но у вас так же? Или я максималист?

Мммм нипонятно

Хочется такого чистого, но никогда не получается. Вот делаешь добро, а потом говорят что нафик не надо. Делаешь модель для увеличения прибыли, а там насрать. Короче сори, наболело, надо идти в архитекторы\сео, и там будет незаметно.

И ещё, свои проекты на мобилке не взлетают, понимаю, что без мАркенига пока ни куда. Возможно возомнил.

вы ж в курсе что люди в чате не в контексте ваших переживаний, да?

Конечно, это так, было сииюминутный порыв, что бы пива выпить и обсудить!