Комментарии 8
Спасибо. Как по вашему, этот подход чем-то принципиально лучше подхода EventSourcing?
С ходу не отвечу, надо изучить.
Но на первый взгляд похоже на нужное решение.
Если есть возможность настраивать события на лету, то описанное решение лучше только тем, что оно проще.
Молодцы, что смогли решить свою проблему малой кровью. Конечно, Event Sourcing может выглядеть несколько сложнее, но в долгосрочной перспективе может быть более гибким решением, к тому же знакомым другим разработчикам. Думаю, для многих было бы интересно поработать в команде, где активно применяется этот паттерн, в принципе
Миллениалы изобрели ERP.
Проще, чем в журнале ручкой записывать…
Интересное решение.
Что думаешь про подход, который выбрали в FreeScout? Тут описание habr.com/ru/post/477918
Цитирую:
По сути там Eventy как диспетчер событий.
1. можно вставлять события в разные части кода ядра или модулей
2. затем из других модулей подписываться на них и реагировать
например:
1. событие — пришла заявка
2. реакция модуля — отправить сообщение в Телеграм чат с содержанием и контактами.
Что думаешь про подход, который выбрали в FreeScout? Тут описание habr.com/ru/post/477918
Цитирую:
Модули разработаны с использованием пакета Laravel-Modules v2. Модули взаимодействуют с приложением через хуки (action и filter) как в WordPress, реализованные с помощью пакета Eventy. Модули могут даже добавлять свои собственные composer-пакеты в проект.
По сути там Eventy как диспетчер событий.
1. можно вставлять события в разные части кода ядра или модулей
2. затем из других модулей подписываться на них и реагировать
например:
1. событие — пришла заявка
2. реакция модуля — отправить сообщение в Телеграм чат с содержанием и контактами.
public function register(string $event): self; Красота.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подсистема событий как способ избавиться от задач по «допилу»