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

+

у тебя примерно такой флоу? сразу создается подтвержденный продукт, после добавления отзыва, продукт становится не подтвержденным, как только подтердили отзыв (если было несолкько отзывов добавлено, то ждем всех), продукт опять становится подтвержденным?

а зачем ему? Ну то есть есть ли такая причина по которой товарам надо знать? Как это влияет на инвариант стэйта этих агрегатов? Может быть товар тоже не один агрегат тогда? может надо пересматривать границы?

Агрегаты != сущности. Агрегаты - это граница твоей логической транзакции. Они дают тебе гарантию что вот этот маленький кусочек стэйта твоей системы всегда консистентный и меняется атомарно.

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

Ну примерно да

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

В более сложных кейсах тебе нужны будут механизмы для достижения eventual consistency агрегатов в твоей бизнес транзакции, компенсационные действия и т.д.

Какое решение выбирать - зависит от домена, зависит от вероятности конфликтов, зависит в целом от того как ты решил все это делать.

Монолит у тебя который в одной базе хранит - у тебя есть варианты закрывать все операции транзакцией в базе. serverless солюшен с document базой - ивенты и компенсационные действия.

Вариантов море. Нужно их все знать просто что бы было из чего выбирать. Универсальных решений нет.

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

Спасибо. Ещё вопрос, который можно было бы загуглить, но хочется узнать ваше субъективное мнение: что на эту тему почитать?

@fes0r Да, спасибо за подробное разъяснение :) Надо осмыслить .

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

сча подумаю, хотя сложно. я книжки мало читаю, я много смотрел докладов всяких и много книг читал наискосок. Может кто предложил еще вариантов но вон на вскидку мой:

- фаулер и его эти Patterns of enterprise application architecture
- эванса можно перечитать даже если читал - там в целом каждый раз читаешь узнаешь что-то новое потому что тогда не понял
- Designing Data-Intensive Applications - хорошая книжка, можно на все эти вопросы декомпозиции с этого угла смотреть
- Еще из того что читал полезно Сэма Ньюмана почитать... у него не плохо.
- Всякие программист прогматики хорошо...

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

вот тут пару хороших книг рекомендуют - я их даже пролистывал

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

(что уж говорить о Фаулере или Эвансе)

по итогу все сводится всеравно к старым добрым:

- open/close (все эти статусы, все эти "жирные агрегаты" быстро приводят к тому что агрегаты нарушают и OCP и SRP)
- information hiding, coupling/cohesion (микросервисы и вот это все - это больше про то как дробить проект что бы можно было лучше паралелить работу над системой - больше организационные штуки нежели технические потому и сложно)

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

Чисто теоретический вопрос. Есть чемпионат по футболу. У каждой команды есть игроки. Нам нужно в лигу добавить команду с игроками. Получается что у нас чемпионат это агрегат. Правильно ли, что мы должны сначала собрать команду (создать, дать имя, добавить игроков) и потом добавить эту команду в чемпионат или это все же 2 процесса?