а если ты послал ивент в диспетчер, то ты не знаешь что с ним дальше происходит

ты не знаешь, что дальше в методе происходит

решаем ивентами ;)

саги?)

саги?)

хорошая попытка, но нет

саги - это только полрешения

хорошая попытка, но нет

чем тебе тут "без ивентов" поможет?

что значит непонятно как? у обьекта есть контракт

ну типа хендлеры могут быть где угодно, хрен найдешь и разберешься.

ну чем, я делаю так: по очереди вызываю методы у внешних сервисов, смотрю результаты вызова, в конце принимаю решение

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

это задача №2

это задача №2

ну так саги ее покрывают)

и если ты забиваешь на задачу номер два - то в чем проблема с ивентами?

ну чем, я делаю так: по очереди вызываю методы у внешних сервисов, смотрю результаты вызова, в конце принимаю решение

внезапно нет разницы начнешь ты этот процесс из-за вызова метода или из-за того, что кто-то ивент бросил

разница между ивентами и не ивентами только в определении “получателя вызова”, в одном случае это использованием средств языка(полиморфизм), в другом это любая динамика сделанного нами диспатчера. Только и всего

саги покрывают последовательность ивентов, но плохо покрывают их отсутствие

разницы для получателя сообщения нет вообще

разница есть для отправителя

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

саги покрывают последовательность ивентов, но плохо покрывают их отсутствие

окей, какая у тебя будет стратегия для задачи номер два?

отправить всем по сообщению в духе "а забудьте"

а если сообщение зафэйлится?

ну ты нормально описал стратегию

саги покрывают последовательность ивентов, но плохо покрывают их отсутствие

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

что с ивентами что без

а как ты знаешь, что он умер? :)

разница будет лишь в том в каком состоянии будет система между

ты же не знаешь про внешние сервисы ;)

ты же толлько про ивент знаешь

ты же не знаешь про внешние сервисы ;)

в этом случае скорее всего за весь юзкейс будет отдельный модуль отвечать который знает последовательность событий

мне не важно кто ивенты кинул - но если ивента небыло например минуту - значит все плохо.

и сервис который эмитит ивенты тоже может у себя в контракте учитывать что "если я ничего не сделал с момента запроса за 50 секунд - то ничего не надо делать"

о! то есть у тебя будет сервис2, который знает последовательность событий, нужных сервису1

не очень красиво но...

коуплинг!

о! то есть у тебя будет сервис2, который знает последовательность событий, нужных сервису1

да, но именно последовательность событий, а не кто их эмитит

коуплинг!

кохижен

это я как ругательство использую

ты можешь в событии например отправить "короч я тебе послал во столько-то, а вот если ты ничего не успеешь до такого-то времени тупо игнорь"

и никакого кауплинга)

и таким образом выстраивать стратегии по хэндлингу таких ситуаций

а еще возможно ты просто будешь делать бесконечный ретрай и тебе из 5-ти сервисов реально нужно будет только 2 что бы пользователь начал работать с системой, просто не вся функциональность ему будет доступна

но для 99% пользователей все будет хорошо

а для оставшихся 1% все будет плохо но не долго

ты не мне послал, ты делаешь так: 1. шлешь ивент в диспетчер 2. ждешь другого ивента от диспетчера 3. если он не пришел за 10 сек, то падаешь с "я упал, причина не ясна"

супер?

ммм

саги чел

дык это и есть саги

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

дык это и есть саги

саги это не только ивенты

да я знаю, я просто не описал вот этот "координатор"

но смотри

координатор знает что? последовательность действий, нужных для регистрации

почему это знает некий координатор, а не сам сервис регистрации?

кохижн!

обработка исключительных ситуаций куда?

что делать с заплутавшими ивентами? (впоминаю башорг про пинг, который 4 дня гулял)

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

cohesion = связность, не?

Почему нельзя использовать оригинальные термины, и обязательно создавать путаницу? Связность, связанность, завязанность, зацепление, привязанность

Почему нельзя использовать оригинальные термины, и обязательно создавать путаницу? Связность, связанность, завязанность, зацепление, привязанность

я и использую оригинальные- кохижен и кауплинг

а, ты Антону

почему это знает некий координатор, а не сам сервис регистрации?

а что ты предлагаешь?)

ну вообще-то я именно и отметил, что ты употребил кохижен и связность в одном предложении

ну вообще-то я именно и отметил, что ты употребил кохижен и связность в одном предложении

связанность а не связность. Я не люблю переводить кохижен ибо никто не понимает.

ивенты снижают связанность. Это так. Но не забывай про coheasion.

в общем я хотел сказать, что нужно было написать ивенты снижают coupling :)

ERROR: S client not available

в общем спор ни о чем. Все всё понимают (надеюсь).

а что ты предлагаешь?)

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

и где-то это всплывет

она помогает избегать циклическиз зависимостей, так лучше?

нет, циклические зависимости не есть проблема сама по себе

ну зависит один рест-сервис от другого, и наоборот

в чем проблема?

в чем проблема?

в том что у тебя циклическая зависимость)

это не проблема, это просто факт

это симптом плохой декомпозиции

если у тебя есть два модуля между которыми есть циклическая зависимость - значит либо это должен быть один модуль, либо у тебя должен быть третий модуль

почему? это нарушает какой-то принцип?

Как по мне если есть циклическая зависимость, то в таком случае нарушается сам принцип модульности. т.е. эти модули нельзя разделить и использовать поотдельности.

ребят, KISS

почему? это нарушает какой-то принцип?

У дяди боба есть такой)

если модули нельзя разделить, то может их и не надо разделять?

ребят, KISS

KISS не в том что бы "втупую нахерачить" а втом что бы можно было тупым людям пользоваться

если модули нельзя разделить, то может их и не надо разделять?

именно

если их нельзя разделить - это один модуль

да блин, ну есть реальный пример из жизни, который работает

да блин, ну есть реальный пример из жизни, который работает

http://wiki.c2.com/?AcyclicDependenciesPrinciple

вот

принцип)

а вот тут про пекеджи, это немного не совсем модули

это куски кода

модули - это что угодно, куски приложения

но не наоборот

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

ок? :)

ну пример из жизни, как и обещал: контейнер, который создает ноды внутри себя, и устанавливает этим нодам парент самого себя

пример циклической зависимости, которая работает как надо