Ахахах

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

https://martinfowler.com/bliki/DDD_Aggregate.html
Как вариант

Можно ли сказать, что если есть агрегаты значит обязательно есть и eventual concistency, либо это полностью независимые штуки?

Нет, не обязательно событийная

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

но разве тогда это не один агрегат?

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

А, тогда понял о чем ты

Для начала - Агрегат это паттерн. Можешь юзать можешь не юзать. Если ты говоришь кому-то что не юзаешь агрегаты и он начинает смеяться - скорее всего ты общаешься с дурачком. Агрегаты имеют смысл там где важные и сложные бизнес рулы. Какой-нибудь профиль пользователя агрегатом делать тупо.

Обычно есть путаница потому что в синей книжке определение агрегата это "агрегат это некий набор доменных объекты представляющих собой единое целое". И народ радостно кричит "ееее у меня есть агрегат User" или там "агрегат продукт". А че? объекты, объединяются. В единое целое! По факту же "единое целое" = "то без чего нельзя убедиться что твои инварианты выполняются и не больше". Короч тут сложно все и к вопросу о том что люди тянутся к абстрактным терминам. Хотя Эванс другому учил но кто его читал на самом деле...

Агрегаты гарантируют консистентность стэйта имидиейт. Что бы этого добиться, нутро агрегата никогда не должно быть изменяемым снаружи. Все должно идти строго через корень (тот объект в котором все лежит). Более того, можно говорить что доступ к агрегату эксклюзивный - это партиция данных. Если у тебя есть агрегат который хотят потрогать 100 человек - все должны трогать его последовательно. По этой причине обычно рекомендуют делать агрегаты как можно более маленькими.

ну вот простой пример - есть у тебя приложение. Приложение занимается например штуками типа документооборота. И есть у тебя правило мол "документ можно опубликовать только если у тебя есть два апрува от ревьюверов". То есть у нас есть некое понятие DocumentStatus которое может быть пендинг или паблишед, и перевести в этот статус можно только согласно условию. Для соблюдения всех правил этот объект в себе должен хранить: айдишку документа. флаг опубликовано или нет. список айдишек тех кто апрувил или же счетчик какой. В целом этого достаточно.

Дальше у объекта DocumentStatus нам нужны будут два метода - approve и publish. Первый будет запоминать что нас заапрувили. Второй - будет проверять правило и переводить в статус. Если шот не то - исключение и не меняем стэйт. Маленький и красивый агрегат. Все. больше туда ничего не пихаем. Вообще.

Агрегаты имеют смысл ТОЛЬКО НА ЗАПИСЬ. На чтение они не нужны и будут мешать (так как ты будешь пытаться больше стэйта в них пихать чем надо). На чтение у тебя нет консернов что "твое чтение приведет к неконсистентному стэйту" и как следствие можно не париться и например данные во вьюшку агрегировать какую.

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

Надо ли делать всю систему на агрегатах - нет это тупо. Например изменение твоего профиля - тут нет конкуренции за ресурсами и сложной логики. Тупой круд. Можно даже по слоям не загоняться.

Вещь которая для меня лично была "откровением" когда-то - есть "бизнес-сущности" - например документ, юзер, прочее... У сущностей есть identify. У агрегатов identity тоже есть (потому что стэйт без identity штука странная), и их тоже технически можно называть сущностями. Что не всегда всем понятно - что два агрегата могут иметь одинаковый айди. То есть агрегат DocumentStatus и DocumentDetails могут иметь один и тот же Document ID

и по итогу как таковой вещи Document  как "объекта" в нашей системе нет - он тупо не нужен. Достаточно заменить его кусками с одинаковым DocumentID. Это открывает очень много интересного в плане возможностей по построению систем

например DocumentDetails - это тупой круд и там можно просто в базу писать напрямую с валидацией. А вот в DocumentStatus уже можно юзать event sourcing (плохой для этого пример но все же)

Тогда такой вопрос. Доменный сервис может манипулировать нескольким агрегатами? И как следствие - репозиториями?

я до сих пор не понимаю смысла "доменных сервисов". По факту именно доменные сервисы не могут вообще машнить вещей с агрегатами

Я так понимаю вот это было как раз про твой вопрос.
“Для простых кейсов ты можешь это игнорировать и завернуть в одну транзакцию в базе. Но факт остается фактом - уже чуть чуть но эвеншуал”

Полезно. Не совсем понял, но пойму. @fes0r , спасибо!

видимо ты говоришь о application services

почитай сверху PDF-ку Вернона про разные варианты дизайна агрегатов. Может быть будет лучше

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

В случае с реально eventual, логика связывающая была бы в саге, а так она в “доменном сервисе”