Можно как то так развернуть твой пример: у тебя есть 2 TableGateways: Blog (id, name) и Comment(id, text, date), что бы реализовать твой инвариант и защитить 10 статей в день, добавляешь агрегат (который в данном случае будет сагой, будет полиси) например с названием TenCommentsPerDay (blogId, day, countComments) или как тебе нравится, главное понимать что защищаем. Дальше при запросе на новый комментарий, загружаем сагу, делаем проверки на день и количество, обновляем стейт в случае успеха и бросаем ошибки в пративном случае, после чего уже сохраняем комент в свою таблицу

Зачем так сложно

Можно через саги - это оправдано когда у тебя обычное дело что 20 человек ломятся одновременно комменты писать

понятно что так делать бессмысленно в данном контексте

Но в целом достаточно иметь агрегат на день.

Вот мы объединили. Один перестал быть агрегатом. Но после того, как мы сделали объединение на основе инварианта добавления, остался репозиторий от старого агрегата, остались юзкейсы (удаление, изменение), которые юзали этот репозиторий и остается доступ к старой сущности мимо рута нового агргатата. Что с этим делать? Оставлять доступ мимо рута или перделывать всё и вся под новый агргегат?

Мол наступает утро - создаём новый агрегат для айдишки и он заменяет собой старый. Он рут и через него создаются комменты

Разделять

Спасибо за развернутый пример :)

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

Есть агрегат блога который следит за тем можно ещё комменты добавлять или нет.

Добавили коммент - по событию пробуем добавит айдишку в блог - не вышло, мол лимиты все - кидает компенсационное действие "удалить коммент".

Это в целом через саги предлагалось сделать

@dexplon у тебя есть доступ к курсу Уди ADSD? если есть, то пример саги из раздела Exercise: saga design, может быть поможет тебе понять как должен выглядеть агрегат, защищающий 10 коментов в день

В чате ссылка была на Яндекс диск с его курсом

Есть, спасибо за конкретную наводку.

Но тут особо разницы в вопросе нет: сага или нет судя по всему. Выходит у блога должен быть доступ ко всей коллекции комментов, чтобы принимать решения. Значит он становится агрегат рутом. Разве нет?
Так же вы написали, что коммент можно редактировать, удалять.  До объединения это делалось через свой репозиторий (баально доступ из БД). После объединения, нужно ли удалять репозиторий комментариев и переделывать удаление/редактирование чтобы теперь это делалось через блог (так как он стал агргегат рутом)? Если да - то зачем.

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

Это я примерно понимаю, хоть и не работал с этим :)

то есть разницы принципиальной нет особо, просто саги дают определенные доп гарантии что сообщение будет обработано

Ну я поэтому и написал, что в вопросе особо разницы с сагой или нет делать - нет. Вопрос что делать с CommentRepository и юзкейсами, которые работали с Comment напрямую.  Ведь по правилам нужно работать только через рут (которым стал Blog)

ну так у тебя в той схеме что я описал например с comment ничего не происходит. он независимо продолжает жить. блогу только айдишка нужна + тебе нужны ивенты какие которые все это связывают. Это именно eventual consistency

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