Комментарии 52
Та достался мне тут один проект на поддержку, где модель служит только для запросов к базе данных… Вся бизнес-логика в контроллерах и вьюхах(
Теперь переписываю, боясь что-то сломать.
Просто понравилась реализация истории заказа, я наверное не додумался бы до такого)
public function insert($runValidation = true, $attributes = null)
{
Yii::$app->MoexOperation->clearing($this);
return parent::insert($runValidation, $attributes);
}
Ничего поэтичного зато выделено. А вы как разделяете?
Don't use Lifecycle Callbacks for Business Logic/Events by @ocramius
Но формирование аудита или лога изменений — уже не ок.
Вот посмотрите пример на самом doctrine
docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html#preupdate
public function preUpdate(PreUpdateEventArgs $eventArgs)
{
if ($eventArgs->getEntity() instanceof Account) {
if ($eventArgs->hasChangedField('creditCard')) {
$this->validateCreditCard($eventArgs->getNewValue('creditCard'));
}
}
}
Валидация номера кредитной карты — это вполне себе бизнес логика.
вполне ОК?
Для очень простых кейсов — возможно. Но подвязываться не события лишенные контекста — это крайне неудобно и будет вызывать проблемы при внесении изменений в бизнес логику.
Вот посмотрите пример на самом doctrine
Увы документация к доктрине далеко не соответствует их же лучшим практикам. Ребята вроде Окромиуса это довольно часто говорят и это один из основных пунктов к "переписать" для 3-ей версии.
Валидация номера кредитной карты — это вполне себе бизнес логика.
если вы посмотрите doctrine best practice то вы увидите что этот пример не имеет смысла. так как у вас никогда не должно быть невалидного состояния в сущностях. Подобная валидация должна происходить еще на подходе к сущности (в крайнем случае в методе который меняет стэйт). Поменять стэйт а потом разбираться что пошло не так — не очень корректный вариант ведения дел.
Отдельно распишу преимущества:
- доменные ивенты проще в отладке
- доменные ивенты по хорошему должны запускаться когда все хорошо, то есть мы можем скажем по
postFlushих обработать и мы точно знаем что транзакция была успешна - доменные ивенты позволяют переходить на более сложные вещи вроде саг. Когда одна логическая транзакция должна либо инициировать другую либо, в случае если что-то пощло не так, компенсировать предыдущие транзакции. Пример. Первая транзакция создала заказ со статусом pending, это привело к доменному ивенту
OrderSubmittedнапример. По этому ивенту кто-то запускает новую логическую транзакцию например для проведения оплаты. Если оплата не удалась, выкидываем событиеPaymentFailed, по которому мы меняем статус заказа на failed.
То есть в целом штука очень гибкая и позволяет нам очень снизить связанность и по настоящему начать выделять изолированные контексты приложения. А так же за пару минут менять тригеры операций, что может дать очень существенный профит в ситуациях когда бизнес еще не определился что когда делается.
Происходят несколько событий, которые должны привести к единоразовому выполнению subscriber.
Пример: вы создали пользователя, дальше меняете ему дату рождения, дальше вы меняете его прописку (привожу примеры атомарных операций, где логично на каждую операцию иметь отдельный метод. то есть не весь апдейт производить в одном методе).
Дальше у вас задача: на все изменения данных клиента отсылать ему СМС
$user = new User($email,$password); // создаем eventUserCreated
$user->changeShippingAddress($address) // создаем eventAddressChanged
$user->changeLegal($lega) //создаем eventLegalChanged.
Любой из eventUserCreated, eventAddressChanged, eventLegalChanged должен вызывать отправку смс.
Как вы предлагаете решать задачу, когда СМС должна уходить только одна (после последнего изменения)?
UPD. Это для AR, где save() может вызываться не один раз.
Для того что бы более-менее корректно вам что-то посоветовать мне нужно лучше понимать вашу бизнес логику. Потому несколько уточняющих вопросов:
- Пользователь может существовать с пустыми значениями для даты рождения, адресов прописки и т.д.? Или это обязательная информация для регистрации?
- Эти данные меняются по отдельности или вместе? Или иногда по отдельности и иногда вместе? Приведите примеры.
- Имеет ли смысл событие
AddressChangedесли это по сути инициализация значения?
Но продолжим с пользователем:
Пользователю для регистрации в магазине достаточно заполнить email.
Дальше он может в ЛК указать ФИО, дату рождения. Если он захочет заказать посылку — он может указать адрес, если адрес не указан — с ним свяжется менеджер и заполнит его данные в админке.
То есть существование отдельных методов на указание адреса, даты рождения отдельно от регистрации оправданно и существует.
В то же время пользователь на полной форме регистрации может ввести эти данные скопом, да еще и фотку загрузить и родственников указать. (Можно дальше копать в реализацию пользователя, но это же только пример того, что несколько атомарных операций могут вызывать отправку СМС).
Допустим, такой вариант кода:
<?php
class User
{
public function changeInfo($userInfo)
{
....
$this->rememberThat(new UserChangeInfo($this));
}
public function changeAddress($adress)
{
....
$this->rememberThat(new UserChangeAdress($adress));
}
public function changeUserAll($userInfo, $adress)
{
$this->changeInfo($userInfo)
$this->changeAddress($adress);
}
}
Наш subscriber подписан на UserChangeInfo, UserChangeAdress.
Пока в коде проблема — при вызове changeUserAll метод subscriber будет вызван 2 раза.
kernel.terminate не вызывается в консоле. Конкретно в этом случае это не важно, но если, к примеру, данные будут обновляться по крону из какой-нибудь API, то как тогда?
если что, кроме kernel.terminate есть еще console.terminate (пруф)
подобное использование консольных команд не особо эффективно (для того что бы это работало нужно на один вызов команды делать одну операцию, что означает много короткоживущих процессов).
Вообще подвязывать подобную логику на такие вот события — наверное не ок. Хотя вариант, скажем, агрегации ивентов по времени (объеденять на уровне консюмера все ивенты от одного и того же агрегата, что-то типа throttle/debounce) тоже не шибко хорошая идея, хотя с хорошим брокером сообщений и хитрой маршрутизацией какой может и норм.
Я в это случае создаю CQRS команду на отправку SMS уведомления на каждое событие и кладу ее в очередь уникальных команд и по крону разбираю очередь.
Это даёт нам и сохранение уникальности уведомлений и позволяет не тормозить клиент на отправку SMS и контролировать нагрузку на сервер отправки SMS.
Давайте на примере заказов:
Пользователь создал заказ:
1) Нужно проверить проверить была ли ссылка на оплату реферальной, если была — пользователю «рефералу» зачислить бонусные баллы.
2) При первом создании заказа начислить пользователю бонусные баллы.
3) После оплаты заказа начислить пользователю бонусные баллы, если он оплатил товар акционной категории.
Пользователь может оплатить спустя время (после подтверждения наличия товара на складе), а может оплатить сразу же (например покупка электронной книги).
Так у нас будет два события:
— заказ создан
— заказ оплачен
После каждого из них мы должны пересчитать бонусные баллы.
И есть три метода:
— создать заказ
— оплатить заказ
— создать заказ и оплатить его (внутри последовательно вызываем «создать заказ» и «оплатить заказ»)
В ответе сервера должна содержаться информация о сумме списания денег, количестве бонусных баллов (отложенную задачу сделать не получится).
Сам я как раз сделал «уникальные команды», но в рантайме, да еще и с приоритетами (сначала обрабатываем события непосредственно оплаты, потом события бонусной программы, потом можем и СМС послать)
Хочется услышать об этом мнения, может быть ссылки на известные реализации и статьи.
После каждого из них мы должны пересчитать бонусные баллы.
мы должны пересчитать единыжды, так? после пересчета создать ивент "бонусы посчитаны" и при срабатывании другого ивента уже не делать этого.
ну то есть, я может быть плохо понял задачу
1) Нужно проверить проверить была ли ссылка на оплату реферальной, если была — пользователю «рефералу» зачислить бонусные баллы.
на оплату или на товар? Ну то есть, вопрос весь в том каков жизненный цикл всего этого дела. А так подобный флоу описывается часто в контексте паттерна сага.
Согласен с Fesor. Очень трудно говорить не зная особенностей бизнеса.
Например мне не понятно почему вы не можете пересчитывать бонусные баллы реферала дважды?
Они пересчитываются по разным событиям и количество начисляемых баллов может, а скорей всего и будет, различаться. Также хорошо бы сохранить в истории начисления баллов за что их начисляли каждый раз. То есть опять же нужно сохранять их раздельно.
По идее, вам надо по каждому событию от заказа пересчитывать баллы рефералов и генерить событие обновления счета, их агрегировать и отправлять рефералу уведомление с подробным отчётом за что и сколько он получил баллов.
Добавлю и свою либу
https://github.com/gpslab/domain-event
бандл для интеграции с Symfony
https://github.com/gpslab/domain-event-bundle
Кроме стандартного агрегирования событий ещё позволяет обрабатывать события в самой сущности, имеет функционал для реализации слушателей, подписчиков, очередей и middleware
позволяет обрабатывать события в самой сущности
Это для воспроизведения событий? ну мол event sourcing?
Пересчет бонусов в сущности заказа?
Скорей: начисление бонусов рефералу за создание заказа.
Пересчет делается в сущности реферала, а вот инициировать процедуру начисления бонусов можно через заказ.
udidahan.com/2009/06/29/dont-create-aggregate-roots/ — вот тут описан схожий пример, к слову.
инициировать процедуру начисления бонусов можно через заказ.
У меня подобное подвешено на события от заказа, в частности когда заказ становится оплаченным.
У меня подобное подвешено на события от заказа, в частности когда заказ становится оплаченным.
Если событие обрабатывается в сущности заказа, как в моей библиотеке, то все гуд. Я это и предлагал.
А вот если вы начисляете бонусы за оплаченный заказ в отдельном сервисе слушателе, то это не есть хорошо. Это пример размазывания бизнес логики по проекту, что часто встречается при использовании событийно-ориентированного подхода.
Ну максимум в доктриновский листенер можно положить время изменения записи, но отправлку письма — это уже переборп.
Вызов метода dispatch достаточно легко заменяется на прямой вызов метода из сервиса, который выполняет все поставленные задачи.
Пару лет назад я тоже так думал когда обжегся с примитивным использованием событий. Спустя какое-то время я пришел к тому, что "замена dispatch на вызов метода" приводит к усложнению управления зависимостями, усложнению тестирования. В ситуациях когда у вас не маленький проект и нужна глубокая кастомизация, это будет приводить либо к проблемам с масштабированием логики, либо к большому количеству медиаторов которые будут работать очень похожим на ивенты образом.
Словом, я бы не стал так категорично говорить о том что "ивенты не нужны". Главный вопрос — как вы с ними работаете. Мне к примеру ни к чему отслеживать "цепочки событий". Мне важно найти причину и следствие, и это как раз таки весьма просто становится сделать. И еще проще — переместить причину (тригер операции какой-то) в виду изменений в требованиях.
Тот случай, когда добавляешь статью в избранное в том числе ради комментариев)
Использование событийной модели в Doctrine 2 + Symfony 3