Size: a a a

Software Design/Architecture/Zen

2021 January 14

SF

Segmentation Fault in Software Design/Architecture/Zen
Ахахах
источник

HH

Human Human in Software Design/Architecture/Zen
atcq (Алексей)
😅 Да, надо изучить вонючую теорию категорий, чтобы понять это определение. Хотя монады, чтобы их просто юзать очень просты
источник

¿

¿hope in Software Design/Architecture/Zen
Segmentation Fault
Проще дать ссылку на статью какую-нибудь
источник

HH

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

SF

Segmentation Fault in Software Design/Architecture/Zen
Human Human
Можно ли сказать, что если есть агрегаты значит обязательно есть и eventual concistency, либо это полностью независимые штуки?
Нет, не обязательно событийная
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Human Human
Можно ли сказать, что если есть агрегаты значит обязательно есть и eventual concistency, либо это полностью независимые штуки?
если бизнес транзакция задействует больше одного агрегата то консистентность стэйта уже больше на эвеншуал консистенси полагается.
источник

HH

Human Human in Software Design/Architecture/Zen
Sergey Protko
если бизнес транзакция задействует больше одного агрегата то консистентность стэйта уже больше на эвеншуал консистенси полагается.
но разве тогда это не один агрегат?
источник

SP

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

HH

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

SP

Sergey Protko in Software Design/Architecture/Zen
Дмитрий
Чувствую себя дураком .  Объясните "на пальцах" что такое агрегат. Чтоб раз и навсегда не путать понятия
Для начала - Агрегат это паттерн. Можешь юзать можешь не юзать. Если ты говоришь кому-то что не юзаешь агрегаты и он начинает смеяться - скорее всего ты общаешься с дурачком. Агрегаты имеют смысл там где важные и сложные бизнес рулы. Какой-нибудь профиль пользователя агрегатом делать тупо.

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

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

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

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

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

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

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

SP

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

SP

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

SP

Sergey Protko in Software Design/Architecture/Zen
например DocumentDetails - это тупой круд и там можно просто в базу писать напрямую с валидацией. А вот в DocumentStatus уже можно юзать event sourcing (плохой для этого пример но все же)
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Тогда такой вопрос. Доменный сервис может манипулировать нескольким агрегатами? И как следствие - репозиториями?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Segmentation Fault
Тогда такой вопрос. Доменный сервис может манипулировать нескольким агрегатами? И как следствие - репозиториями?
я до сих пор не понимаю смысла "доменных сервисов". По факту именно доменные сервисы не могут вообще машнить вещей с агрегатами
источник

HH

Human Human in Software Design/Architecture/Zen
Segmentation Fault
Тогда такой вопрос. Доменный сервис может манипулировать нескольким агрегатами? И как следствие - репозиториями?
Я так понимаю вот это было как раз про твой вопрос.
“Для простых кейсов ты можешь это игнорировать и завернуть в одну транзакцию в базе. Но факт остается фактом - уже чуть чуть но эвеншуал”
источник

Д

Дмитрий in Software Design/Architecture/Zen
Полезно. Не совсем понял, но пойму. @fes0r , спасибо!
источник

SP

Sergey Protko in Software Design/Architecture/Zen
видимо ты говоришь о application services
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Дмитрий
Полезно. Не совсем понял, но пойму. @fes0r , спасибо!
почитай сверху PDF-ку Вернона про разные варианты дизайна агрегатов. Может быть будет лучше
источник

HH

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

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