Как организовать управление логикой Observer pattern из места генерации события?
Всем привет,
Давно использую Observer pattern в Laravel, но обнаружил, что довольно часто недостаточно просто сгенерировать абстрактное событие, на пример создания нового объекта. Довольно часто у этого события могут быть дополнительные свойства, сообщающие дополнительные обстоятельства. На пример, когда я создаю новый объект User на форме может быть checkbox, который определяет подписан пользователь на новости или нет.
В целом, если эти данные сохраняются в модели User, то вопроса нет - проверяем уже на уровне слушателя есть параметр или нет и если нет ничего не делаем.
Но тут возникает вопрос того, как правильно организовать такую логику, ведь
1) Этих данных может не быть в модели
2) Таких параметров, теоретически, может быть много. И они могут формироваться из разных других параметров. На пример, возможно, User создается для офиса, который предполагает дополнительную бизнес-логику (на пример тут должен так же активироваться лисенер, отправляющий дополнительный пакет документов новому пользователю)
И тут не очень понятно как организовывать такое "управления" со стороны кода, генерирующего событие. Из того, что первое приходит в голову - это:
1) В объекте события добавить атрибут extra и описывать там в форме срок дополнительные свойства, которые потом будут как-то проверятся слушателями
2) В коде, генерирующем событие создавать отдельный события для каждого уникального кейса, но тогда скорей всего это будет 1 событие на 1 лисинер и не понятно чем это будет отличаться от прямой передачи запроса.
Раскажите, пожалуйста как вы организуете такой код или что почитать на эту тему?
