Оо, ты и тут есть

а как же без меня ?

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

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

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

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

вспомнил статью касательно использования ивентов http://mmoreram.com/blog/2015/08/20/re-thinking-event-listeners/ интересно ваше мнение

как кто то говорит о событиях вспоминается вот этот доклад https://www.youtube.com/watch?v=SyWFvn0I6m8

кому интересно можно полную версию посмотреть но там про фронтенд

Много нового узнал.

ото все о solid, ddd,dry, kiss и тд рассказывают скучные бородатые мужики

нету веселья

пояснил за ивенты

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

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

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

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

какой бы пример привести

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

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

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

Тут как никстати подошла бы SOA, но увы, php

Тут как никстати подошла бы SOA, но увы, php

php не мешает)

Он не подходит для SOA =|

че это?

ну и как бы soa это тип "ну чувак теперь тебе придется делать это на ивентах/сообщениях")

че это?

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

и чем пхп не подходит?

А в php как бы все кучей исполняется

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

никто не оговаривал что процесс не должен умирать

в смысле кучей?)

А в php как бы все кучей исполняется

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

просто слегка глупо

Делать сервисную архитектуру на php - это странно, т.к. придется для каждого сервиса юзать отдельный php процесс

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

похоже на твой пример/задумку: http://www.whitewashing.de/2012/08/25/decoupling_applications_with_domain_events.html

Делать сервисную архитектуру на php - это странно, т.к. придется для каждого сервиса юзать отдельный php процесс

у тебя так и так отдельные php процессы

В общем-то в монолите - нет

Я наверное неясно выразился

В общем-то в монолите - нет

окей, тогда давай так. SOA в контексте монолитной архитектуры не имеет ровным счетом никакого смысла

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

Астанавись

микросервисы - полезный вид SOA

ты не понял меня

я не понял тебя)

там Ольга правильную ссылку кинула

Под процессом php я подразумевал отдельную php-машину на каждый процесс

Под процессом php я подразумевал отдельную php-машину на каждый процесс

я опять не понял. Что, почему отдельная машина, зачем это?

и давай мыслить "контейнерами" (мы же модные?)

Да

Мало ли, вдруг ты про докер не слышал

Ну так вот, в SOA, каждый сервис - является контейнером по сути

и между ними по ресту (или RPC, или еще чему угодно) гоняются сообщения

там Ольга правильную ссылку кинула

лучше просто Оля ?

лучше просто Оля ?

Оке)

и между ними по ресту (или RPC, или еще чему угодно) гоняются сообщения

ну я вкурсе что такое soa

Ну так вот, в чем суть моего посыла, лучший вариант для модульности - SOA

делал и soa (где rabbitmq между компонентами был шиной) и микросервисы

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

окей, как бы ты в рамках soa архитектуры делал бы то что я описывал?

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

так?

Неужели ты сам не догадываешься, как тут использовать принцип SOA?)

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

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

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

Неужели ты сам не догадываешься, как тут использовать принцип SOA?)

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

вот только нет гемороя с поддержанием распределенного приложения

ERROR: S client not available

Ой, ну кто как называет. Кому то разделение обязанностей не кажется гемороем

Ой, ну кто как называет. Кому то разделение обязанностей не кажется гемороем

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

распределенные архитектуры крутые, не спорю, но у меня прям дикий батхерт когда люди просто так говорят "да не парься, заюзай SOA/микросервисы"

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

а точнее не то что минусов... цены

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

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

я сказал про снижение связанности за счет ивентов

а не про модульность

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

Объясни джуну, как эвенты могут выглядеть, как SOA

Объясни джуну, как эвенты могут выглядеть, как SOA

вот смотри, мой пример ты рассмотрел, предложил SOA

у тебя в рамках одной будут два компонента - users и referral system

так?

Да

вот а теперь скажи, как бы ты с SOA сделал бы так, что бы users ничего не знало о referral system но при этом дергало бы его при успешной регистрации пользователя при определенных условиях

хотя бы примерно

где и кто дергал бы кого по RPC/HTTP/etc

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

Другой контекст это другое приложение с другим сабдоменом

А зачем юзеру дергать реферальную систему?

ну, в смысле, оно вроде по другому работает

сначала дергается реферальная система

Другой контекст это другое приложение с другим сабдоменом

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

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

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

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

А в твоем тсходном приложении, не будет с этим никакой бл

А в твоем тсходном приложении, не будет с этим никакой бл

бл?

бл?

Бизнес- логики, тупаю команда в дпугую сисиему

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

есть инвайтер юзера. Он нужен не только для рефералки

рефералка постоянно раскидывает людям в бэкграунде какие-то бонусы

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