CQRS и аудит доступа к данным

Question

Как шаблон CQRS связан с аудитом доступа к данным?Или может ли это?

Позвольте мне привести некоторые сведения:

У меня распределенная система.У него есть несколько «Разделов».Каждый раздел занимается частью бизнеса.(Один выполняет заказы, другой выставляет счета, а другие клиенты и т. Д.)

Я планировал, чтобы каждый раздел отправлял сообщения о бизнес-событиях друг другу (т. Е. Создан заказ, зарегистрирован новый клиент и т. Д.).Затем события могут быть сохранены и воспроизведены в стиле CQRS.

Я также планировал, чтобы в каждом разделе была база данных, которая им нужна из других разделов (заказы будут вести основной список клиентов, биллинг будет содержать простой список заказов и т. Д.).Эти данные будут получены с помощью сообщений о бизнес-событиях.

Я знаю, что это не "True" CQRS.Но я думаю, что мой вопрос относится к CQRS все же.

Итак, как в CQRS работает аудит доступа к данным и защиты данных?Нужно ли просто верить, что все последующие системы будут правильно проверяться?(Очень долгий срок доверия)

Мой Архитектор не любил CQRS по этой причине.Вместо этого мы будем использовать сервис в каждом разделе распределенной системы, который будет отправлять запросы на данные.Таким образом, аудит (и безопасность) можно проводить в центральном (контролируемом) месте.

Итак, есть ли у CQRS стратегия аудита доступа к данным, которую я не вижу?Или CQRS только для систем, где данные не нуждаются в контроле? (или я полностью упускаю из виду CQRS?)

На всякий случай, если это имеет значение: я работаю с Visual Studio 2010,C # 4, .NET 4, WCF 4 и NServiceBus 2.6

Answer 1

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

Answer 2

Я не думаю, что в самом паттерне есть какой-то встроенный механизм для этого - так как вы сказали: «Надо ли вам просто верить, что все нисходящие системы будут правильно проверять?» - да.

Просто чтобы уточнить, хотите ли вы проводить аудит таких вещей, как «кто какие данные просматривал, когда» (т.е. данные, специфичные для пользователя)? Или вы хотите проверять, какие сообщения были отправлены какой системой, когда (т.е. данные о системных событиях)?

В любом случае, я думаю, что, возможно, вы уже используете CQRS, даже если у вас есть «тесно связанная» центральная служебная шина - все зависит от того, как разработаны ваши классы. CQRS и CQS - это всего лишь механизм для разделения вашего кода, давая каждому классу отдельные обязанности. Единственная разница, по-видимому, заключается в том, что «CQRS» обычно включает «сообщения», выводящие разрозненные системы, тогда как «CQS», по-видимому, подразумевает разделение «метода», выводя, что оно находится в одной области приложения. Я думаю, что некоторые люди очень много думают о том, чтобы иметь сервисную шину как «требование» для решения, которое следует рассматривать как CQRS. Ознакомьтесь с этим объяснением аргумента о разнице потенциалов между CQS и CQRS: http://codebetter.com/gregyoung/2009/08/13/command-query-separation/. В конце дня разделение обязанностей, как правило, является хорошей идеей.

Чтобы попытаться ответить на ваши конкретные вопросы:

• "Есть ли в CQRS стратегия аудита доступа к данным, которую я не вижу?" - нет, как шаблон, у него нет механизма «аудита». Это зависит только от его реализации.
• «это CQRS только для систем, где данные не нуждаются в контроле» - нет, абсолютно нет. Я внедряю CQS / CQRS в «простые» веб-приложения, потому что я думаю, что он хорошо выделяет код. Смотрите мой блог на этом: http://www.nootn.com.au/2013/03/command-query-separation-to-better.html

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