Можете подсказать по поводу DDD и агрегатов. Так все таки можно за один запрос модифицировать несколько агрегатов или нет ? Два типичных примера 1) Заказы и клиенты. Это разные агрегаты. Но во время создания заказа анонимным пользователем, требуется создать анонимного клиента. 2) Регистрация пользователя. На форме может быть куча данных, которые ссылаются на разные агрегаты. В дальнейшем эти агрегаты будут отдельно модифицироваться, но при регистрации нужно создать все в одной транзакции (то есть чтобы была не конечная согласованность, а транзакционная).
Тут скидывали ранее ссылку на статью Вернона по агрегатам и вот во второй части вроде (она про взаимодействия между агрегатами) писалось, что как-бы в сервисе уровня приложения это норма обращаться к разным агрегатам через репозитории или доменные сервисы, но вот это не повод модифицировать больше одного. Я так и не понял, это совет или прям без этого DDD не DDD. Лично я думаю, что если это разовая оперция, где должны модифицироваться несколько агрегатов, то норм. Но хотелось бы услышать мнение экспертов, ну или как минимум тех, кто пробовал несколько раз использовать DDD в проде и сталкивались с такими проблемами.

если делать это все в транзакции то можно

если нет, можно ненароком порвать контсреинт где-нибуть и что-то сломать

согласен. Я имел ввиду именно в рамках одной транзакции

агрегат вроде как граница транзакции, зачем их в 1 объединять непонятно
мне кажется, что если хочется так сделать  - можно подумать "а нужно ли?". Либо "а правильно ли выбраны границы?"

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

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

Ddd плевать агрегаты там у тебя или нет. Оно больше про то что твои технические штуки часто скрывают бизнес проблемы.

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

Единственный консерны это возможность partial failure. Мол есть два агрегата, один важный второй не оч. Второй фэйлит всю операцию и на этом все.

Если для тебя это желаемый результат то ок.

Что до ddd - оно не про код и не про паттерны. Оно про моделирование и анализ problem space и как это все мэпить на solution space

Я понял, спасибо за объяснение

@fes0r , ты не с русско-говорящими коллегами работаешь?

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

Почему многие пытаются добавить DDD туда где оно не нужно?

почему люди думают что DDD не нужно?)

наоборот , лучше бы писал всегда на английском.

Потому что не понимают зачем оно… Это я типа ответил на свой вопрос?

тип того.

Но в целом так всегда когда не столкнулся с проблемами которые оно решает. Но как звучит... "domain driven design..." Это как микросервисы или там ~аджайл~ lean. Модно

еще бы что-то существовало помимо этой моды

ну думаю ты помнишь мой вопрос о применении ооп для технических задач

Модно? Считаешь что погоня за DDD может прекратиться?

в реальности никакой погони нет. У тебя просто выборка по чату где в описании есть DDD.

большинство знать не знает кто такой Эрик Эванс и что это за три буквы