про шины команд вобоще-то, читай дискуссию с начала

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

или one-way комманд

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

а зачем?

чем это будет лучше вызова сервиса?)

прямого, без шины

шина скрывает большое число подписчиков

возможно с разным интерфейсом

и прочим

ну т.е. это абстракция над вызовом метода

Че ты опять реальный мир моделируешь?

нет другого мира, кроме реального, и всё программирование - моделирование реального мира

когда просто вызова недостаточно

шина скрывает большое число подписчиков

просто я не уверен, что кому-то здесь бывало необходимо запустить команду (не ивент!), которую обработают разные хендлеры

Эвент асинхронным может быть?

ну т.е. это абстракция над вызовом метода

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

не знаю что такое асинхронный вызов)

просто я не уверен, что кому-то здесь бывало необходимо запустить команду (не ивент!), которую обработают разные хендлеры

у меня хэндлер на команду может быть только 1. Не могу представить ситуаций, где это может быть не так

у меня хэндлер на команду может быть только 1. Не могу представить ситуаций, где это может быть не так

вот и я о том же

не знаю что такое асинхронный вызов)

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

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

лол

не знаю что такое асинхронный вызов)

это когда ты попросил сделать но когда оно сделает и чем там как не знаешь)

ты просто попросил и тебе пофиг что там дальше

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

добавь await туда и все

ты просто попросил и тебе пофиг что там дальше

не, тогда не согласен что это нужно для шины

и это нужно там где так взаимодействие организовано. Именно по этой причине я говорю что "шины команд не нужны в 95% ситуаций где их юзают"

не, тогда не согласен что это нужно для шины

это нужно для шины, шина не нужна в большинстве ситуаций)

зачем такая шина тогда вообще

что шины не нужны я согласен

но те, которые не могут собрать результат не нужны еще больше

повторюсь - шина скрывает то куда идет команда

да

в кролика, мидлвары, маршрутизация

какому процессу слать сообщение если ты просто шлешь через IPC

ну то есть такого рода вещи скрываются

шины не нужны, команды должны быть синхронными... много набросов за день)

"отправка сообщения" а не RPC вызов

messaging а не процедуры

повторюсь - шина скрывает то куда идет команда

А без шины не скрывает?

ну я согласен со всем, кроме one-way. Какие-то обрезанные шины

А без шины не скрывает?

просто если что-то скрывает, то его обзовут шиной

ну я согласен со всем, кроме one-way. Какие-то обрезанные шины

попробуй добавить задачу в очередь не one-way

это называется RPC

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

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

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

просто если что-то скрывает, то его обзовут шиной

нет, просто если оно работает как шина данных - то это обзовут шиной

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

А если не шина?

А если не шина?

шины*. То у тебя просто вызов методов разумеется)

А если не шина?

назови маршрутизатором) суть не сильно изменится. Оно знает что и куда передать. Усё

Придумали какое-то название для read и write синхронного

И теперь спорят

Придумали какое-то название для read и write синхронного

нет. только для write

и для очень специфичных ситуаций

нет. только для write

сеттер

сеттер

ты какой-то очень неумелый троль

ну он синхронный

и write

ты фронтендщик да?)

Не подходит что ли

чёт я нить потерял...

чёт я нить потерял...

да он на РО нарывается, я на 90% уверен что он понимает о чем разговор и в чем разница между write моделью и сеттером)

ну я согласен со всем, кроме one-way. Какие-то обрезанные шины

помнишь я тебе рассказывал про безумную идею с actor model на php?

там между прочим все взаимодействие с write model было однонаправленным

что за безумная идея?)

и весь поток данных однонаправленный

actor model это rich Domain ??

что за безумная идея?)

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

actor model это rich Domain ??

ненене

actor model это rich Domain ??

actor model это actor model

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

а как ты знаешь, какие данные грузить ? оо

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

ну вполне вариант)

я в видосе хоть слегка понял, что есть actor model

а как ты знаешь, какие данные грузить ? оо

процесс-координатор знает какие воркеры каких экторов держат. И могут маршрутизировать команды нужным воркерам

что бы те попали в нужные экторы

если эктора под команду нет - в каком-то из воркеров он стартанет

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

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

понятно что для языков типа эрланга или го

(по сути из нынеживущих только языки на эрланг vm, а их два только))

ну и go как вариант в пределах одного сервера

я потому и говорю про "безумие")

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

нет. только для write

А read?

А read?

на read просто методы дергай

у меня на рид аще приложение отдельное... жизнь - тлен)

А для асинхронности event sourcing?

А для асинхронности event sourcing?

почитай что это такое

А для асинхронности event sourcing?

чё?)

короч все

А для асинхронности event sourcing?

ну ты ж так не набрасывай

получаешь РО

ой все

сегодня что-то обострение у него

обычно поадекватнее слегка

чёртовы анимешники)

о, привет)

ох нифига себе

Это селебрити или шо?)

получаешь РО

Дико извиняюсь, что есть РО?

ридонли