A
а где можно прочитать по событийную модель?
Size: a a a
2018 January 31
SP
я всякими там domain events упарываюсь
SP
ну то есть это не такое событие как обычно, а именно факт того что что-то произошло. Ну мол если у тебя есть ивент что кто-то что-то сделал - значит это уже факт
SP
ну это удобно когда ты еще всякими там ddd загоняешься и прочими модными словами
A
тогда получается лучше создать таблицу с уведомлениями (с ссылками на данные факта) и информацией о просмотре уведомления
A
а пуш информацию тут же хранить или отдельно?
SP
зависит от того важно ли тебе различать их или нет
SP
обычно это не важно, но допускаю что иногда надо отдельно
SP
ну мол обычно push это лишь способ доставки. У меня например пользователь может выбрать 3 типа доставки (или все три) но нотификация то одна и та же
A
мне важно учитывать количество пуш уведомлений суммарно в день/неделю, время отправки
SP
ну ты можешь отдельно лог вести как и чего и когда ты отправлял, или просто доп поле в табличке типа как оно было отправлено
A
и это по мимо этих уведомлений, потому что есть куча других триггеров для пушей
SP
ну мол... тут уже как удобно. Я просто предпочитаю всю логику нотификаций максимально отделять от логики которая эти нотификации порождает (типа юзер что-то сделал - создался доменный ивент, листенер подписался на этот ивент и отправляет нотификашки. А что там и как внутри - зависит от задачи)
SP
и это по мимо этих уведомлений, потому что есть куча других триггеров для пушей
ну если не только нотификашки вызывают пуши - то тебе надо на уровне инфраструктуры метрики трекать
SP
я бы во всяком случае так делал, тупо логгером каким
SP
или промитей бы настроил
A
я думал про elk для логирования
SP
ну короч тут все очень зависит от того что ты юзаешь, что тебе надо и т.д
SP
я думал про elk для логирования
я для таких целей использую prometheus
SP
ELK удобно что бы посмотреть что делалось