даже не сага, а транзакция

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

- команда -> сбрось пароль - ивент -> пароль сброшен, вон новый - листенер -> отправляю команду, надо послать письмо мудаку и сказать ему новый пароль - сайд эффект - письмо ушло

Команла не сбрось пароль

А дай мне ссылку на сброс

Т. Е до отправки емайла я не могу быть уверен что событие свершилось

Т. Е до отправки емайла я не могу быть уверен что событие свершилось

после отправки тоже не можешь

А дай мне ссылку на сброс

команда: хочу сделать запрос на сброс пароля ивент - запрос сделан, вон временный токен листенер - о, надо отпавить письмо мудаку сайд эффект - письмо ушло

- команда -> сбрось пароль - ивент -> пароль сброшен, вон новый - листенер -> отправляю команду, надо послать письмо мудаку и сказать ему новый пароль - сайд эффект - письмо ушло

> мудаку > забывчивому мудаку

ну и да - можно просто сделать декоратор вокруг сервиса нотификаций который разруливает твои эти параметры под юзера

команда: хочу сделать запрос на сброс пароля ивент - запрос сделан, вон временный токен листенер - о, надо отпавить письмо мудаку сайд эффект - письмо ушло

Ок, а где тогда получить язык и домен?

Т. Е до отправки емайла я не могу быть уверен что событие свершилось

за это листенер же вроде будет отвечать

Ок, а где тогда получить язык и домен?

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

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

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

Там сложнее

Язык не от юзера

Там сложнее

ну сложнее - думай)))

А от много чего

В ряде случаев от запроса

ну формализуй задачу тогда поговорим

У нас много сайтов, использующих апи наше партнёрское

И надо знать откуда пришёл запрос обязательно

ну блин чел, пили кастыль, все так делают

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

Я предложил три варианта 1 из которых считаю менее гавнистым

Но мне по чабжу никто пока ниче не сказал)

я тебе уже говорил: твой менее говнистый вариант менее говнистый

но в общем и целом твое построение команд говнистое

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

https://dev.tube/ фактически - агрегатор видосов по теме с ютуба сейчас, походу, собирают все интересное

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

? не ленись)

я тебе уже говорил: твой менее говнистый вариант менее говнистый

Почему гавнитстое я так и не понял

Есть команда получить ссылку на пассворл резет

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

С определёнными опциями

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

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

Вот еще плюс в мою точку зрения. ДОпустим я решил делать по вашей схеме запрос на емайл с сылкой резета => событиеРезетЛинВозРеквестед И событие обрабатывается допустим в порядке очереди откуда то, мне же надо получить данные, которые существовали во время запроса? Надо. А если бы я это делал в рамках сервиса отправки писем, то контекст был бы другой(был бы вообще непользовательский запрос на франзузском языке от партнера somepartner.com а просто консольная окмнада на выборку очереди), а т.к у меня сохранен контектс я смогу извлечь язык и партнер

Вот еще плюс в мою точку зрения. ДОпустим я решил делать по вашей схеме запрос на емайл с сылкой резета => событиеРезетЛинВозРеквестед И событие обрабатывается допустим в порядке очереди откуда то, мне же надо получить данные, которые существовали во время запроса? Надо. А если бы я это делал в рамках сервиса отправки писем, то контекст был бы другой(был бы вообще непользовательский запрос на франзузском языке от партнера somepartner.com а просто консольная окмнада на выборку очереди), а т.к у меня сохранен контектс я смогу извлечь язык и партнер

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

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

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

чтобы понять от имени какого сайта и на каком языке отсылать письмо

чтобы понять от имени какого сайта и на каком языке отсылать письмо

у тебя одна база юзеров на все сайты?

да

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

то есть ты ресетишь пароль а сайте А и меняется на остальных?

или у тебя юзер закреплен за каким-то сайтом?

ну то есть либо у тебя 1:1 юзер-сайт либо у тебя другие проблемы)

Да меняется на всех. Юзер не закреплен технически. Но он может не знать вообще что он зареган на 1000 других сайтах

Да меняется на всех. Юзер не закреплен технически. Но он может не знать вообще что он зареган на 1000 других сайтах

есть ли случаи когда юзер зареган больше чем на одном сайте?)

есть ли случаи когда юзер зареган больше чем на одном сайте?)

так он на всех сразу и зареган))

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

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

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

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

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

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

Если 1 раз попытался заресетить, то нужно ждать или определенное время до следующей попытки, или перейти все таки по ссылке и сделать резет

Если 1 раз попытался заресетить, то нужно ждать или определенное время до следующей попытки, или перейти все таки по ссылке и сделать резет

я к тому что юзеры всеравно охуевать будут

от такого положения дел

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

команды/ивенты не подразумевают наличия шины)

ERROR: S client not available

я к тому что юзеры всеравно охуевать будут

ну это уже не программная часть

такая модель монетизации

ну это уже не программная часть

тебе за код пишут или что бы проблемы решать?

такая модель монетизации

ну тип у тебя проеб уже на этом уровне, о чем мы дальше поговорим?)

команды/ивенты не подразумевают наличия шины)

прямой вызов диспетчеров?

прямой вызов диспетчеров?

ивент диспатчер != шина.

оно похоже но все же чуть проще

ивент диспатчер != шина.

ну да, само собой

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

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

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

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

пока телега лежала - я тут вопрос писал никто не встречал подобных штук, но без завязки на гит? http://gitgraphjs.com/ хочу описывать потоки команда-ивент

пока телега лежала - я тут вопрос писал никто не встречал подобных штук, но без завязки на гит? http://gitgraphjs.com/ хочу описывать потоки команда-ивент

я просто пока юзаю плагинчики под d3.js

или вообще можно через graphviz

второй не оч, я хочу хранить исходники в репе тоже

http://www.webgraphviz.com/

а, интересно

надо подумать

У меня есть 4 gateway для работы с 4 нодами. Каждая нода возвращает ответ в виде json, у каждой ноды он разного формата (и разные требования валидации). На данный момент у меня на каждую ноду по одному Response классу, который имеет метод result() - с отформатированным и провалидированным результатом. Так же есть метод make(string json) (возвращает инстанс своего класса), который парсит и валидирует полученные данные. Так же в этом методе падают исключения при ошибке валидации либо парсинга. Вопрос - как это нормально переписать, что бы респонс был респонсом, а не сборной солянкой?

при этом у меня часть валидации глобальная для всех респонсов, а часть - только для конкретного респонса

на ум приходит респонс фактори

остается вопрос - оставлять ли валидацию в респонсах?

либо делать унифицированный респонс, в который будет инжектиться валидатор под конкретный гейтвей

композиция респонсов?

зачем все так сложно фоли?)

Потому что хуй знает

просто ты вчера еще писал я сразу говорил ты хуйню делаешь )