CQRS - Как мне обработать пользователя, просматривающего страницу или запрос

Question

Я использую CQRS для создаваемого приложения (онлайновая дискуссионная система со сложной бизнес-логикой), и я достиг той реализации, которая меня беспокоит.

Как мне поступитьпросЕсли пользователь просматривает тему, я хочу отслеживать это.Поскольку я хочу это отследить, из этого следует, что я должен создать команду и событие и связать их с совокупным корнем, который отвечает за просматриваемый объект (например, UserViewsThread и UserViewedThread, соответственно).Но это кажется в целом неэффективным - кроме этого, нет никаких причин обращаться к объединенному корню во многих случаях использования системы обсуждений (просмотр форумов / тем).Теперь, когда я представляю это, у меня будет дополнительная диспетчерская команда и публикация события на каждом просмотре страницы, что, в свою очередь, отвечает за «подкачку» агрегата потока, сериализацию моего события и отправку его моему событию.издатель.

Должен быть лучший способ сделать это.Я думал о том, чтобы, возможно, сделать так, чтобы мой объект контроллера мог отправлять события - но, обходя мой агрегат, я больше не могу прикреплять поведение к просмотру страницы.

Другая возможность - это использовать это какспособ аутентификации моего пользователя.Командам UserViewsThread и UserViewsForum будет разрешено генерировать исключение аутентификации, чтобы мой контроллер знал, что пользователь не может выполнить это действие.Но если бы они должны были быть преобразованы в события и сохранены в моем хранилище событий, мы говорим о нескольких событиях, создаваемых на каждом просмотре страницы - которые могут очень сильно снизить производительность (каждый просмотр страницы приводит к базе данныхтранзакция ... тьфу) и управление ресурсами.

Что думает твой парень?

Answer 1

Использование CQRS не означает, что каждое крошечное взаимодействие с приложением - особенно если я связан с инфраструктурой - должно проходить цепочку команд / событий.Отслеживание просмотров страниц - это сквозная задача, которую легко реализовать отдельно.

Просто заставляет запросы в слое чтения увеличивать счетчик для соответствующих моделей просмотра в некоторой таблице при каждом вызове.

Как только вы начинаете создавать команды, которые изменяют состояние каждый раз, когда вызывается запрос, вы снова тесно связываете чтение и запись, и все преимущества разделения команд / запросов сводятся на нет.Во-первых, вы используете CQRS для разделения двух проблем.

Answer 2

Мы делали почти так же, как это.Но неправильно отслеживать все, как это, ваши чтения должны быть быстрыми и не требовать никаких записей.

Мы закончили тем, что добавили объект отслеживания ко всем нашим событиям, но я не думаю, что сделаю это снова.Я хотел бы написать некоторый javascript, такой как Google Analytics, и создать отдельную команду из внешнего интерфейса.

Также я бы выделил вашу очередь отслеживания и вашу обычную очередь.

Answer 3

Вы можете захватывать информацию отслеживания в сеансе и время от времени отправлять ее на сервер.

Кроме того, как вы думаете, зачем вам нужен AR с хранилищем событий, чтобы отслеживать эту информацию? Я бы собрал эту информацию в каком-нибудь хранилище на основе состояния.

Answer 4

Похоже, это веб-приложение, поэтому я бы создал атрибут (asp.net mvc / WebApi), который будет обрабатывать просмотры страниц.Конечно, атрибут будет вызывать только сервис INFRASTRUCTURE (так как я думаю, что статистика отслеживания не является частью домена), который просто обновит просмотры страниц в хранилище.Проще говоря, сервис вызывает Dao, который обновляет персистентность (обновляет набор записей просмотров страниц = просмотров страниц + 1).

Конечно, атрибут может просто отправить асинхронную команду для обновления просмотров страницы, которая будет выполняться в фоновом режимепоэтому «записи» фактически не будут мешать чтению.

Если ваше приложение имеет / будет иметь большой трафик, я бы предложил следующую стратегию сохранения: иметь таблицу PageViews (PageId, ViewsNumber, TimeStamp), где вы просто добавляете строку для каждого просмотра страницы.Затем каждые X минут, есть фоновый сервис, который будет делать Sum (ViewsNumber) GroupBy (PageId), где TimeStamp> oldTimestamp.У вас не будет статистики за миллисекунду, но она будет обновляться достаточно часто, и приложение будет реагировать.

Я не считаю это беспокойство частью какого-либо домена за пределами случая, когда вы создаете систему Google Analytics., так что вам не нужны AR, DDD или Event Sourcing.В вашем случае статистика страниц - это информация, прикрепленная к странице, а не часть страницы.Они рассматриваются вместе только в модели чтения, где вы фактически отображаете их в одном представлении.