Я не уверен, является ли это официальной «лучшей» практикой, но в целом я считаю, что Event Sourcing и использование событий для управления записью и обновлением модели чтения являются хорошей практикой. С источником событий модель записи живет не как сущности и отношения в реляционной базе данных как таковая, а как история событий (я знаю, это поначалу звучит довольно запутанно)
Вы можете узнать намного больше об источнике событий, посмотрев, как Eventide реализует его (в Ruby) https://eventide -project.org / .
У меня также есть краткое введение в CQRS с использованием событий домена здесь: http://lucisferre.net/2010/11/04/a-brief-introduction-to-cqrs/
Тем не менее, это на самом деле не отвечает на ваш непосредственный вопрос, и в конечном итоге поиск источников может быть не для вас. Поскольку вы сохранили состояние своей модели записи в реляционной базе данных, триггеры - один из возможных путей, но вы делаете свою систему очень ориентированной на данные. Было бы намного чище и более тестируемым, если бы вы могли сделать то же самое, используя триггеры в коде.
Для этого я все равно использовал бы шаблон событий домена и использовал бы шину событий для публикации событий в обработчиках событий, которые отвечают за обновление модели чтения.
Думайте об этих событиях и обработчиках как о ваших триггерах SQL, но основываясь на дизайне вашего домена и его поведении. Уди Дахан имеет много хороших материалов об этом подходе, где доменные события используются для обновления модели чтения, но источник событий не используется. http://www.udidahan.com/?blog=true