Маленькое добавление - все это верно пока ты юный начинающий разработчик. Как только ты доходишь до Enterprise, Event-Drven Architecture и Cloud Computing - правила игра меняются
Alex Dmn, что, же, успехов) просто есть далеко не один печальный пример когда поступали именно так. Если проект на года от это значит что команда будет постепенно меняться, как и требования как к отдельным модулям так и ко всей системе. В длительных проектах ТЗ годится только для старта или отдельных модулей. В остальном - Agile ваше все. Я пока не видел ни одного разработчика, который умеет смотреть так далеко, что очень хорошо. Задача разработчика сделать законченный неизменяемый модуль по строгим спецификациям.
devmailer, S - SOLID. Single Responsibility. Отправитель не должен принимать решения, а только выполнять задания.
Вы, конечно, можете организовать Shared Cache и держать там список пользователей для той или иной группы рассылки.
Зайдите с обратной стороны - если у вас между отправкой уведомления и его генерацией достаточно времени для изменения настроек пользователя это значит так же что пользователь может не получить те уведомления на которые подпишется, поскольку пул уведомлений будет сформирован. Если у вас медленный канал связи (например, email или sms) то об этом вообще можно не беспокоиться. Такие сообщения имеют свойство иногда теряться, увы.
1. больше ЗП разработчика это ну очень относительно
2. Если вы не позаботиться об архитектуре проекта то потом у вас будут большие проблемы с развитием спустя несколько лет, а может и раньше.
3. Даже если разработчик FullStack это не значит что он знает как строить проекты. Скорее всего он будет просто реализовывать ваши потребности. С Senior Developer все получше, но эти люди имеют свойство иметь ограниченный инструментарий
jtag, советую прочитать документацию по генератору. Признаюсь, я с ними не знаком, поскольку разрабатываю сейчас больше для AWS, а там несколько другие правила игры.
Если документация не поможет, то можно и вручную. Оба варианта принесут свой уникальный опыт
Друзья, давайте жить дружно) чуть ниже я уже изложил работающий механизм для любого случая. Можете к нему добавить не реалитайм, а регулярный анализ очереди и создание уже реальных заданий на перерасчёт рейтинга в другую очередь.
