Size: a a a

Software Design/Architecture/Zen

2021 July 26

V

Vitaly in Software Design/Architecture/Zen
привет
раз тут event storming затронули, можете поделиться о своих успешных/не успешных историях внедрения этого подхода? какие ресурсы (видео воркошопов или книга Брандолини, например) в самом начале помогли больше всего и вообще может советы для тех, кто только внедряет это все?
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
не оч понимаю причем здесь прокси(и зачем они вообще нужны в рассуждениях, какая-то орм деталь)?

с точки зрения кода агрегат можно описывать как функции имеющие тип как я выше описал, код его изменения может быть примерно таким: changeAggregateById(someId, someAggregateAction)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Есть время - есть стэйт
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
никто от стейта не убегает, тут скорее вопрос в разных методах его описания
источник

SP

Sergey Protko in Software Design/Architecture/Zen
А, тогда ладно
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Хотя честно - хз чё разного можно, если есть adt
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
акцент на если
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Даже если нет это не повод кучу нулабл полей делать, ну тоесть на сами модель это будет мало влиять
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
это наверное не относится к моему изначальному комменту про возможность описания изменений как функций без мутаций. Куча нуллабл полей - обычно говно и лень
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
не, мы можем вместо того чтобы хранить в агрегаете его эвенты, обернуть его в глубокий прокси и собирать изменения в этом прокси, т.е. как раз у нас будет имутабельный агрегат но в коде это так выглядеть не будет
короче сложная хрень, редко так делают
но я все ещё не понял зачем делать
[event] = aggregateAction(aggregateState)
или мб я не так как-то воспринял то что вы написали
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
ну т.е. если мы так делаем то зачем нам вообще агрегат, если он не накапливает эвенты в очереди
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
зачем делать - потому что можно, и тогда скорее будет функция, которая принимает id и этот метод изменения и сама внутри достанет агрегат, вызовет метод изменения, заберет новые ивенты и сохранит, т.е. с точки зрения вызывающего будет выглядеть как-то так: changeAggregateById(someId, someAggregateAction), где changeAggregateById как раз и будет искать актуальные стейт, вызывать action, забирать результат и сохранять
источник

DP

Dimitry Polonskiy in Software Design/Architecture/Zen
adt?
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
вкусовщина какая-то, надо будет в любом случае где-то хранить эвенты отдельно для каждого агрегата до коммита, чтобы управлять временем обработки, по итогу просто состояние будет менее локальным сразу
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
коммит происходит внутри changeAggregateById
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
ясно, это execCommand(someCommand, someData)  только прибитое к одному агрегату, тогда это ничем не отличается от складирования эвентов в агрегате
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
отличается, тем как по итогу методы описываются
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
а, порядок событий в коде будет явно определен, это вообще дает какой-то ощутимый профит? Хотя думаю это делает чуть более прозрачной квантовую запутанность хендлеров)
источник

HH

Human Human in Software Design/Architecture/Zen
algebraic data types
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
с этим сокращением есть прикол: abstract data types и algebraic data types оба adt, но первое это обычные классы, а второе это объединение/пересечение классов)
источник