не выйдет так сделать, если я сейчас не туплю

но лучше иди в лара чатик

Через Query Builder вручную

точне выйдет, но не через отношения, а вручную

+

Прикольно

Потому что такая штука не осилит разрулить ситуации вроде "добавить not null поле без default" и "преобразовать one-to-many в many-to-many" на БД с данными

Ну первое разруливается, там это вполне на уровне описания схемы выразить можно.

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

переддд

а разве агрегаты это только про ддд?)

вы знаете за агрегаты?)

Ух, если то, что пишет Сергей по моему вопросу, то мне надо будет сутки на осознание того, что написано

Мы тоже пишем уже лет 10 как, но ни разу не роллбекали бд, хотя код бывает. Тьфу-тьфу.

если мы говорим про event sourcing то принятие решение о границах агрегата ты должен принимать больше на основании того, как ты хочешь партиции раскидать.

Грубо говоря тебе нужны гарантии сохранения последовательности событий в стриме (конкретного агрегата - считай агрегат партицией данных). Это обычно делается за счет того что версия у ивента есть (курсор стрима считай) + обычная оптимистичная конкаренси (код выставляет новую версию и база падает по uniq constraint в случае если чего не так).

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

Например у меня был кейс - есть агрегат "заметки" которая строится на основе какой-то формы. Если все обязательные поля формы заполнены мы можем подписать "заметку". После этого менять форму уже нельзя.

Логика форм сложная. логика заметок слоожная. Держать все в одном агрегате - больно. И есть два пути:

- забить и просто сделать так что бы работа с этим агрегатом несколькими людьми была последовательна (очереди) - тут есть риски но в целом "сойдет" на не оч больших нагрузках
- пересматривать важность и вероятность нарушений инвариантов. Мол "если мы подписали и кто-то в ту же секунду чего-то в форме подправил - это оч плохо?" А если мы собираемся подписать и еще не пришел апдейт что кто-то поменял что-то?

У меня все было проще ибо "добавленную форму" никак больше нельзя поменять, то есть "логика" становится весьма стабильной и я просто ссылался на нее + инфраструктура раскукоживала ссылку на форму (айдишку) в полноценный объект с логикой (не хотел в стриме дублировать все).

за пару лет с симфони, мне кажется я делал когда-то роллбеки миграций на проде, но не помню даже уже зачем. Это случается так редко, что не запоминаю и вообще ощущение, что такого никогда не было 🤔

я помню зачем я делал - кто-то накосячил и добавил не нулабл колонки и зафэйлился деплой)

я вот все хочу потратить пару вечеров и запилить проверку совместимости схемы

тут даже не про конкаренси по большей части. Нагрузка пока минимальная, а про то, что если к этим формам будет доступ через сам агрегат - то да, он будет пухнуть. А если это будет сущность (Entity), то можно ли в агрегате держать реф на нее? Если да, то как принимать решения исходя из состояния сущности, когда у тебя есть только реф? опрашивать напрямую?

находил готовые но они оч странно работают и сложна