Межуд каким частями? Как это использовать?

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

Можете обновлять данные для чтения

Не понимаю, можно боеле конкретные примеры пожалуйста

письма смски

какие-нить расчеты

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

whenUserRegistered(UserRegistered event) { return mailer.sendWelcomeEmail(event.userId, event.email) }

Хз ченить такое

Не понимаю, можно боеле конкретные примеры пожалуйста

два момента: - отправка уведомлений разного толка (email/браузер/пуш уведомления на телефон). Организуется явная связь "тригер" и "действие по тригеру". - связь нескольких контекстов (разные части приложения которые мы хотим друг от друга отделить, дабы упростить поддержку) - построение проекций на чтение. То есть например у тебя есть рефералка и ты хочешь граф строить из нее для аналитики. Кидаешь ивет что мол пользователь зарегался а в листенере уже строишь модель на чтение.

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

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

Спасибо, пойду пробовать

ну вот тебе еще на подумать. Посмотри на свои сущности и прикинь как проперти оной использутся на запись. Если у тебя там 10 пропертей скажем а в разных операциях на запись используются только 2-3 поля всегда, и можно всегда выделить какие-то закономерности типа "вот когда такие операции мы дергаем вот эти 2 поля, а когда такие - вот эти 2, а эти операции по смыслу отличаются". Это может говорить (А может и нет, если тебе удобно) что сущнсти стоит разделить и положить в разные модули. И вот для организации взаимодействия этих модулей доменные ивенты хорошо заходят

но сразу предупреждаю что это все довольно сложно ибо требует от тебя и думать зачем ты что и почему ты что куда ложишь, и с чтением потом возникают нюансы (симфони из коробки мало возможностей предоставляет что бы с этим удобно было работать), и в целом если проект маленький (скажем до 20K строк, как самый простой способ померять) то может и загоняться не надо....

не, тут система

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

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

ну вот было бы занятно придумать упражнение

какое?

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

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

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

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

Идея хорошая, нужно больше примеров чистого кода! Но у меня скиллов не хватает ?

Идея хорошая, нужно больше примеров чистого кода! Но у меня скиллов не хватает ?

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

а во вторых с визуализацией связей (вот с этим я сча воюю для своего проекта)

а во вторых с визуализацией связей (вот с этим я сча воюю для своего проекта)

ERD недостаточно?

@fes0r мм, что за проект?

ERD недостаточно?

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

@b101010 я миллионы слал

@b101010 я миллионы слал

Куда? В /dev/null?

Это типа шутка такая?

Ты спросил кто рассылал почту и что-то знает. Я ответил. Есть вопросы - задавай по существу

Ты спросил кто рассылал почту и что-то знает. Я ответил. Есть вопросы - задавай по существу

Что за сервис юзал, AmazonSES или Mailchimp?

Ни то ни то. Сами делали систему.

Ни то ни то. Сами делали систему.

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

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

миллионы дорого на mailchimp, это тот масштаб на котором в целом инвестиции в свою систему могут окупиться

миллионы дорого на mailchimp, это тот масштаб на котором в целом инвестиции в свою систему могут окупиться

Я просто с такими объемами(несколько сотен тысяч сообщений в рассылке) встречался будучи на поддержке ИМ, там не парились и AmazonSES использовали.

ну то есть если мы сравниваем 25 центов за 1000 имейлов и нам надо слать 100M каждый месяц, уже есть смысл

а если до пары миллионов - смысла особо нет

ну то есть исходить все же надо из соотношения затраты/окупаемость

ну то есть исходить все же надо из соотношения затраты/окупаемость

А разве нет готовых self-hosted решений?

А разве нет готовых self-hosted решений?

там большая часть проблем типа "а как не попасть в спам базу" а как это все мониторить и т.д. Много подводных камней. И с учетом того что 1M на каком-нибудь sendgrid обойдется тебе в $250 (я не знаю какой у тебя рейт, сам посчитаешь сколько будет стоит пара месяцев разработки и тестирования) то желания делать велосипеды резко убавляется. Тем более что если у тебя есть кому слать этот миллион email-ов то скорее всего ты бы лучше эти ресурсы пустил на что-то другое

Подпишусь. Люди часто хотят сэкономить на таких вещах, но реальная экономия, если посчитать, начинается когда миллионами в день письма шлются. Тогда да, можно попробовать сэкономить на своем решении. А, ну да. Есть еще спамеры :) но мы, надесь, не про них

Подпишусь. Люди часто хотят сэкономить на таких вещах, но реальная экономия, если посчитать, начинается когда миллионами в день письма шлются. Тогда да, можно попробовать сэкономить на своем решении. А, ну да. Есть еще спамеры :) но мы, надесь, не про них

ну там лучше в ботнет инвестировать

Ты спросил кто рассылал почту и что-то знает. Я ответил. Есть вопросы - задавай по существу

Какой рейт в секунду с одного ip приемлем?

Прежде чем ответить, хотел бы провести краткий ликбез. Почтовым серверам, ровно как и к людям в реальной жизни есть определенное доверие/недоверие ос тороны почтовых вендоров (Гугл, мелкософт, яблоко и тысячи других). От того, насколько хорошая репутация у сервера зависит сколько писем ты можешь слать, не опасаясь попасть в бан. Репутация складывается не только из того, сколько писем ты шлёшь, но и от того как ты это делаешь,что у тебя в письме, есть ли у тебя нужные подписи в служебных заголовках, есть ли у тебя обратная запись у сервака и кучи других мелочей

Помимо крупных вендоров есть мелкие получатели, типа компов под столом сисадмина в школе. Они, например, могут быть "спрятаны" за каким-нибудь сторонним решением, типа фильтра стороннего сервиса. Есть довольно крупные фильтры, с которыми приходится считаться. Для них нет каких-то особых правил, однако попадание в такой чревато перенаправлением трафика на иных вендоров, т.к. конкретно из этих спам листов почти не возможно вылезти. А тех поддержка там не работает вообще)))))

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

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

Если у тебя какой-то сервак слал 20к писем на мсн и в ус не дул, а ты такой решил на него накинуть 8к, типа а фигли. Можно словить резкое падение репутации. Так как в относительных цифрах прирост почти 50 проентов

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

Если хотите прочувствовать что бывает в случае повышения трафика, попробуйте недельку послать через Гугл апи 10 писем, а потом отправить 100. Сразу в бан

Что-то увлекся. Я все)

Познавательно, спасибо.

Уважаемые знатоки, внимание, вопрос: Используется No-SQL БД, при определенном действии диспатчется событие, на событии висит листенер, который баланс пользователя обновляет. Сейчас нашлась бага, что по какой-то причине баланс не обновился. По закону Мёрфи оказалось, что я bugsnag неверно чуток сконфигурировал и ошибка не залогировалась... Собственно вопрос в другом, как предотвратить такие факапы при таком конфиге(отсутствие транзакций)? Двуфазные коммиты чет вообще не ок, может есть проще решения? З.Ы. деньги виртуальные, проект ещё в дев, так что не бойтесь, никто не пострадал... пока... :)

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

ну хотя бы failed jobs гдето складировать... и вообще я сразу про ES подумал :)

у меня скоро на любую проблему будет ответ - ES

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

Я же вроде рассказывал тебе, с какими перлами тут работаю, лол. ? Пока что из No-SQL решений только Elastic не вызывал боли используемый по прямому назначению. А все эти MongoDB и JSON(b) / HStore только палки в колёса вставляют, где документы не атомарные :(

ES конечно круто, но во-первых - у меня лапки и нет опыта, чтобы сразу так запилить, во-вторых, уже поздно. ??‍♂️

и, в-третьих, не поможет ни чем)

и, в-третьих, не поможет ни чем)

ну если без транзакций, то да.

саги велкам)

саги велкам)

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

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

ну, тут уж стоит задуматься: шашечки, или ехать)

ERROR: S client not available

я тут с тобой согласен :)

Я же вроде рассказывал тебе, с какими перлами тут работаю, лол. ? Пока что из No-SQL решений только Elastic не вызывал боли используемый по прямому назначению. А все эти MongoDB и JSON(b) / HStore только палки в колёса вставляют, где документы не атомарные :(

А можно пояснить чем jsonb не?

Или имеется ввиду не pgsql?

А можно пояснить чем jsonb не?

Ну я работал на фрейме где AR, для поддержки JSONB приходилось писать "маппер", сверху костыли на поиск и обновления по ключам документа... В общем, готовил не правильно по неопытности. Надо четко понимать все подводные, выбирая JSONB.

а эластика типа из коробки без камней работает?

если да, то что за тул такой

докер

докер

?

?

а че за камни?

я подумал про гемы)

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

а, не читал)

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

вот типо есть сущность, она кидает событие и у нее метод

protected function whenStreamCaptionWasChanged(

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

private function when*, private function on*

Оба варианта в целом

я имел ввиду определение))

вот то что мы бросаем в event bus это у нас слушают листенеры

а тут у нас оч странно сделано типо событие бросатес внтури сущности черзе метод aply и оно само себя же слушаешь

Ну это листенер в чистом виде. Какая разница откуда эвент появился) хотб рефлексией, хоть хуками изнутри)

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

У меня, к слову, так же сделано.

Эвент через aply записывается в стрим и накладывается через листенер

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

$stream->apply(new VideoStreamCommentWasPosted($comment));

и обработка здесь

Ну, да

function whenStreamCaptionWasChanged(

Оно так и работает)

Когда этот листенер вызывается, меняется стейт на данные из события