Здесь просто добавляется своя спицифика, когда начинаешь работать с микросервисами, у тебя появляются саги, которые хотят чтобы ты реализовывал методы отмены на некоторые методы, и следить за тем, успешно ли отработал сервис, и успешно ли отработала отмена становится на порядок сложнее, потому что, например, транзакция_1 могла пройти, а на транзакции_2 БД отвалилась. В таком случае компенсирующая транзакция гарантированно отвалится, так как консистентность БД уже была нарушена и админ злой пойдет читать логи))

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

Ну это выходит правио на уровне кода :) Типо можно наговнять а можно и нет) Все же это должно ифраструктурно поддерживаться имхо.

с любыми правилами можно наговнять, а можно и нет

Save не должен быть в репозитории. Сейв - отдельный интерфейс

Можно сразу в отдельный микросервис

Есть и такие варианты, со сложными, к примеру, сагами

Но это совсем крайний случай

А что например делать с кейсом, когда агрегаты хранятся в разных БД? Как тут save работать будет? Или ваше решение подразумевает отдельный save интерфейс под каждый агрегат?

Отдельный под каждый. Дженерики - это не хорошо. Но обычно, хватает и дженерика

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

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

@fes0r Спасибо!

Всем привет, такой вопрос. Если я измнил логику немного логику одного значения, но это значение хранится в базе и на проде уже есть записи с этим значением. Мне нужно сделать так, чтобы после деплоя какой-то одноразовый скрипт обновил значения в бд. Как это сделать "правильно"? В ларавеле я создавал миграцию и там это делал, а как это делается в симфоне? Или просто пишется команда, а потом вручную один раз запускается на проде?

можешь делать в миграциях, так же как и в ларавели (только миграции обычно до деплоя запускаются), можешь вызывать при деплое команду... как тебе удобнее

у меня команда отдельная запускается после деплоя для миграции данных. Что бы миграции схемы отдельно, миграции данных отдельно.

Руками?

а ты деплоишь руками?

2 вариант

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