Size: a a a

Software Design/Architecture/Zen

2021 January 14

HH

Human Human in Software Design/Architecture/Zen
Доменный сервис - будущая сага?)
источник

SF

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

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

SF

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

SP

Sergey Protko in Software Design/Architecture/Zen
есть domain services которые про бизнес логику, есть application services которые про оркестрацию.... так ты про какие?
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Sergey Protko
есть domain services которые про бизнес логику, есть application services которые про оркестрацию.... так ты про какие?
Ты кому адресуешь вопрос?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
тебе
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Ну используй реплаи
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Sergey Protko
есть domain services которые про бизнес логику, есть application services которые про оркестрацию.... так ты про какие?
Про доменные
источник

SP

Sergey Protko in Software Design/Architecture/Zen
грубо говоря - если бы просто спросил "какие штуки могут машнить несколько агрегатов" - я бы ответил "апликейшен сервисы". Могут ли доменные сервисы машнить несколько агрегатов - не уверен.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
агрегаты + доменные ивенты как-то полностью убирают для меня необходимость в доменных сервисах которые работают с чем-то кроме VO. При этом их достаточно мало
источник

SF

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

SP

Sergey Protko in Software Design/Architecture/Zen
Segmentation Fault
Вот например операция выдачи правд доступа юзеру, которая сопровождается изменениями в хранилище. Это доменная операция? Или и там и сям?
не, это про оркестрацию. Сначала делай одно потом другое. За это application level сервисы отвечают
источник

SP

Sergey Protko in Software Design/Architecture/Zen
альтернатива - юзер кинул ивент "поменялись права" и другая штука подписалась на ивент и сделала чего с "хранилищем" (к слову что это?)
источник

a

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

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

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

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

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

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

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

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

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

SP

Sergey Protko in Software Design/Architecture/Zen
основная ценность и предназначение "доменных сервисов" насколько я могу сформулировать - возможность убрать логику из application services.

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

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

SF

Segmentation Fault in Software Design/Architecture/Zen
Sergey Protko
альтернатива - юзер кинул ивент "поменялись права" и другая штука подписалась на ивент и сделала чего с "хранилищем" (к слову что это?)
Сохранила связь: юзер - база данных
источник

HH

Human Human in Software Design/Architecture/Zen
Sergey Protko
не, это про оркестрацию. Сначала делай одно потом другое. За это application level сервисы отвечают
а разве задание порядока не является частью бизнес правил?
udp: правда наверное какая-разница как это называть
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
atcq (Алексей)
@fes0r вот по поводу твоего ответа

я читал синюю книгу от эванса и мне решительно не понравилось как она написана
знаешь ли книги по DDD и смежным темам с более конкретным стилем изложения, может быть похожим на твой?
Поддерживаю на счёт синей книги. Слишком абстрактно, конкретики маловато
источник

SP

Sergey Protko in Software Design/Architecture/Zen
atcq (Алексей)
@fes0r вот по поводу твоего ответа

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

SP

Sergey Protko in Software Design/Architecture/Zen
Human Human
а разве задание порядока не является частью бизнес правил?
udp: правда наверное какая-разница как это называть
шутки про "просто добавь квантовый ко всем словам и будешь выглядеть круто" заказывали?
источник