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

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

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

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

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

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


person Community    schedule 14.09.2010    source источник


Ответы (4)


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

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

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

person Dennis Traub    schedule 18.11.2012
comment
Стоит отметить, что у совокупного корня могут быть серьезные проблемы с параллелизмом, если каждый просмотр страницы будет генерировать событие. OP должен использовать statsd для целей отслеживания, так как это очень быстро — вы можете обрабатывать просмотры страниц за кулисами и обновлять модель домена на основе собранных данных. - person Jacek Kobus; 08.09.2017

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

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

person Rinat Abdullin    schedule 20.09.2010
comment
То, что просматривают пользователи, может иметь большое значение для отчетности. Если моя инфраструктура отчетности использует хранилище событий для ответа на события в мою модель чтения, тогда я смогу создавать более детализированные отчеты на основе представлений пользователей о конкретных запросах. - person ; 20.09.2010
comment
Лично я предпочитаю просто использовать Google Analytics для отслеживания посещений. - person Rinat Abdullin; 22.09.2010

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

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

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

person Owen Davies    schedule 18.11.2012

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

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

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

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

person MikeSW    schedule 18.11.2012