Можно ли использовать CQRS паттерн в GO?

[@kilgur]

Скажите, а где у вас тут CQRS? Я не придираюсь, мне термин CQRS до вашей статьи незнаком был, ходил в википедию почитать. Если правильно уловил суть, то должно быть разделение чтений и изменений. Т.е. мухи и котлеты запросы и команды — отдельно. Дважды просмотрел ваш код, вижу только publish-subscribe паттерн. Я как-то неправильно понимаю эту «кухню»?

[@zelenin]

увы) в статье нет CQRS и есть реализация простейшей шины событий.

[@BOOTLOADER]

Вы правы — я не стал добавлять репозитории для чтения данных и в результате получилась реализация шины. Ценность это в стать, при отсутствии EventSourcing небольшая, но делает статью урезанной. Я тогда добавлю.

[@claygod]

Недавно по CQRS была статья, думаю, пригодится не только вам (если предмет действительно интересен) но и автору статьи: habrahabr.ru/post/347908 Там довольно интересное обсуждение получилось в комментариях…

[@BOOTLOADER]

Спасибо. Почитаю.

[@Workanator]

Также, вместо того, чтобы создавать переменную h_in_gorotine, её можно передать, как параметр функции.

[@GeckoGreen]

А с какой целью аргументы в Publish заворачиваются в reflect.Value?
Так же стоит заметить, что recover повсюду не есть хорошая практика.

[@BOOTLOADER]

Так же стоит заметить, что recover повсюду не есть хорошая практика.

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

[@GeckoGreen]

За то вызовет обработчик панику или нет, должны отвечать тот кто пишет сам обработчик и тот кто передает обработчик в шину. Так например, для сервера из net/http все обработчики тоже неродные, но никаких recover в нем нет.

[@BOOTLOADER]

Ну допустим у вас есть 6 обработчиком. Что лучше — один обработчик на уровне шин, или шесть recover на уровне каждого хандлера? И если скажем кто-то где-то забыл поставить recover вся шина упадет.

[@GeckoGreen]

Лучше не паниковать вообще, а возвращать ошибки. А что если хэндлер решит запустить горутину и в ней паниковать? Вся программа упадет.

[@BOOTLOADER]

Да, вы правы — если внутри хендлера запустить goroutine и они уже выбросить панику, то все упадет.

[@kilgur]

В данном случае это может быть библиотека и код обработчиков для неё чужероден, т.е. доверять ему нельзя. Обработчик может и панику выкинуть, но шина от этого падать не должна… На мой взгляд, recover здесь вполне уместны.

[@BOOTLOADER]

А с какой целью аргументы в Publish заворачиваются в reflect.Value?

В reflect.Value преобразовывыл потому, что все равно значение передаются как интерфейсы и нужно будет анализировать значение через рефлексию, но немного поразмыслив я понял, что я не совсем был прав и нужно оставить самому хендеру выяснить что за значение переданы и как с их обрабатывать, и теперь все параметры передаются также как interface{}

Спасибо. Вы также меня натолкнули на мысль, что будет если один их хендлеров изменит значение параметров и тут у меня оказалось ошибка. Я добавил тест (Test_Should_not_leak_args_changes_to_another_handler), чтобы проверить, что параметры от обработчика к обработчику не меняются. И если в методе Publish --> подменить строку h_in_goroutine.Execute(cArgs ...) на h_in_goroutine.Execute(args ...) тест упадет, потому что значение параметров из первого хендлера попадают во второй. К сожалению не могу вам добавить "+" из-за низкой кармы…

[@stranger_shaman]

добавлению по средствам различных интерфейсов
поправьте чтоли

[@BOOTLOADER]

Изменил, спасибо.