Тоже озабочей темой правильного сохранения изменений в DDD, в том числе и для корня агрегации. Вроде как методологически через репозиторй нельзя делать `save/update`, только `add/delete`.
Многие на эту тему говорят об использовании концепции UnitOfWork, которая должна решать данный вопрос вроде такого:
OrderRepository.add(Order)
UnitOfWork.save()
Так что если у вас появилась новая информация буду рад услышть.
Денис Сафронов: В священном вопросе Redis или Mongo выбирать нужно то, с чем уже умеешь работать или интересно разобраться, а так же от задач которые предстоит решать в ближайшем будущем. потому как и там и там есть свои + и -. =)
Денис Сафронов: Для >10k подписчиков на элемент нужно организовывать промежуточную очередь, чтобы не потерять уведомления, в случае сбоя скрипта в середине выполнения. Тоесть $feed->push($data) кладёт в базовую очередь событий. Затем скрипт (несколько экземпляров), который слушает эту очередь получает подписчиков по событию и записывает в следующую очередь атомарные события (мол этому пользователю такое уведомление, или этому пользователю такую запись в ленту), а уже следующий уровень разбирает весь этот завал, например, в 5-10 потоков (тут уже масштабирование от загрузки очереди).
Что касается удаления, то если шардить и иметь возможность расширяться, то можно и не удалять вовсе =) А если всё же удалять попроще и быть экономным, то можно пошамать с организацией шардинга данных. Например: если сделать ключ [пользователь, временной-фрейм] и вынести часть логики в приложение, то можно просто периодически дропать целые неактуальные коллеции.
Денис Сафронов: Всё верно, менеджеры очередей позволяют асинхронно формировать ленты пользователей и не зависеть от их кол-ва и активности.
Монга как раз отлично для этого подойдёт с её schemaless, конечно при условии её правильной настройки. Только если у вас пользовательские ленты основа сервиса, то заранее подумайте о том, чтобы иметь возможность восстанавливать ленты за определённый срок, например, железно сохраняя часть последних событий. Потому что вдруг что-то пойдёт не так или захочется "всё сделать по другому".
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Многие на эту тему говорят об использовании концепции UnitOfWork, которая должна решать данный вопрос вроде такого:
Так что если у вас появилась новая информация буду рад услышть.