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

cqs, юху :D

ну простите, CQS Мэйер сформулировал еще в 80-х. И не он его по сути выдумал)

по поводу архитектуры - архитектура это всегда наличие ограничений, которые призваны дать какую-то характеристику. Гексагональная архитектура - про направление зависимостей и инверсию зависимости. Это дает тебе гибкость в плане изоляции бизнес правил от инфраструктуры. Если тебе это надо - можешь туда смотреть. Если тебе надо организовать какую-то децентрализацию - можно другие ограничения рассматривать. Ну и т.д. Если мы попробуем выстроить аналогию между знакомыми тебе ООП штуками и экторами.... представь себе систему, простенькую... есть объект представляющий какую-то сущность. Например сделаем простенький todo список. В языках типа Java и в целом наследующих объектную модель всяких там симмул и C++, у тебя будут объекты на каждый список, будут объекты для каждого элемента списка и ты будешь работать как бы с ними. Будешь просить добавить новую тудушку в список, можешь просить "Завершить" конкретный элемент списка и т.д. В этом примере "объект" является не более чем границей зоны ответственности на уровне рантайма. То есть у тебя есть "внутри" и "снаружи", есть другие объекты с которыми нам надо взаимодействовать. В языках типа Erlang за "границы" отвечают микротреды. То есть это такие вот штуки на уровне рантайма которые позволяют тебе изолировать состояние. На каждый список будет тред, который отвечает только за список. Для работы отдельными элементами и их деталями мы можем сделать свои треды.... по треду на каждый агрегат (штуки учавствующие в бизнес транзакции). Ну и все это обменивается сообщениями. Теперь важный момент отличающий "вызов метода объекта" от "отправки сообщений" - наличие мэйлбоксов. То есть наш "эктор" отправляет сообщение другому, и все сообщения являются асинхронными по своей природе. Отправил сообщение и все. Положил его в мэйлбокс эктору а эктор как освободится почитает. Он может тебе прислать какой-то результат и положить уже в мэйлбокс первого эктора и т.д. Это решает вопрос синхронизации действий. Ну и так как "общих данных между экторами нет" - нет необходимости хоть что-то лочить (мэйлбоксы можно тоже лок-фри сделать). У тебя в целом получается полностью неблокируемая система. Для телекомов это вообще было смертельно важно потому именно в этом контексте эрланг и развивался.

А в чем отличие от bus тоже самое я кладу в маилбокс(шину) сообщение(команду или ивент) и тоже не знаю че там будет

Т.е я отпавляю запрос в майлбокс, и жду что мне кто то на него ответит?(не зная кто) Это мне напоминает медиатор уже

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

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

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

Можно послать синхронный запрос (call) в gen_server, тогда отправитель на своей стороне начинает ждать ответа именно на это сообщение. Сообщения имеют уникальные id. Это как сделано в erlang. Можно просто послать запрос и не дожидаться ответа. Это будет асинхронный запрос

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

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

ну так если ты послал его асинхронно - тебе никто не гарантирует скорость ответа

а если синхронно кто-то гарантирует скорость?)

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

Можно послать синхронный запрос (call) в gen_server, тогда отправитель на своей стороне начинает ждать ответа именно на это сообщение. Сообщения имеют уникальные id. Это как сделано в erlang. Можно просто послать запрос и не дожидаться ответа. Это будет асинхронный запрос

Не обязательно, чтобы все акторы общались только асинхронно, это же с ума можно сойти

Это без очередей

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

гулп еще жив?)