CQRS или служба приложений?

Question

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

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

Мой первый вопрос: подходит ли мое приложение (традиционное приложение MVC / Relational DB)? Или имеет больше смысла иметь традиционный слой приложения и использовать DTO Mapper?

Мой второй вопрос: имеет ли смысл выдавать команды для модели вашего домена из традиционного уровня приложения? Мне нравится идея команд / обработчиков команд и событий.

Позвольте мне уточнить мой вопрос. У меня есть проблемы с фильтрацией данных, связанные с авторизацией. Когда пользователь запрашивает данные, должен быть фильтр, который ограничивает доступ к определенным элементам данных, удаляя их все вместе (чтобы они не возвращались вызывающей стороне), скрывая значения или применяя маски к данным. В надуманном примере для номера социального страхования пользователь, выполняющий запрос, может видеть только последние 4 числа, поэтому результат будет выглядеть как ###-##-1234.

Я утверждаю, что эта ответственность лежит на прикладном уровне. Я считаю это аспектом, когда все ответы на запросы или команды должны проходить через этот механизм фильтрации. Вот где проявляется моя наивность в CQRS, возможно, команды никогда не возвращают данные, а просто указывают на данные, которые просматриваются в модели чтения?

Спасибо!

Answer 1

Прежде всего: CQRS и реляционные базы данных не исключают друг друга. В сложных сценариях может иметь смысл заменить БД на основе SQL другими средствами хранения, но CQRS как концепция не заботится о механизме персистентности.

В случае нескольких представлений, которые зависят от ролей и / или пользователей, слой Thin Read, вероятно, должен предоставлять несколько наборов результатов:

1. Тот, который содержит полный SSN для пользователей, которым разрешен доступ к этой информации.
2. Другой для пользователей, которые не авторизованы, чтобы видеть эту информацию
3. ...

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

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

public class AuthorizationHandler {

    public CrmAuthorizationService(CrmCommandHandler handler) {
        _next = handler;
    }

    public void Handle(SomeCommand c) {
        if (authorized) _next.Handle(c);
    }
}

// Usage:
var handler = new CrmAuthorizationService(new CrmCommandHandler());
bus.Register<SomeCommand>(handler.Handle);

Таким образом, вы можете вкладывать несколько обработчиков, например, в конверт REST, для регистрации, транзакций и т. Д.

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

Первое: подходит ли CQRS для вашего приложения? Никто не может сказать, не углубляясь в конкретные требования. То, что вы используете MVC и реляционную БД, ничего не значит, когда дело касается плюсов и минусов CQRS.

Второе: да, в некоторых случаях может иметь смысл позволить вашему прикладному уровню взаимодействовать с клиентом классическим способом и обрабатывать такие вещи, как аутентификация, авторизация и т. Д., А затем выдавать команды внутри. Это может быть полезно при размещении пользовательского интерфейса на основе MVC или REST API поверх вашего приложения.

Обновление в ответ на комментарий:

В идеальном, пуристическом сценарии CQRS Салли будет иметь свои собственные денормализованные данные для каждого представления, например, пару документов в базе данных NoSQL с именем CustomerListForSally, CustomerDetailsForSally и т. Д. Они заполнены тем, что ей разрешено видеть.

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

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

В действительности у вас, вероятно, есть какая-то система на основе пользователя / роли или пользователя / группы. Чтобы иметь возможность просматривать конфиденциальную информацию, вы должны быть членом определенной роли или группы. Каждый из них может иметь определенный набор представлений и команд. Эти данные не обязательно должны быть деноализованы. Они могут быть такими же простыми, как и класс SQL-Views:

• CustomerDetailsForSupportStaff
• CustomerDetailsForSupportExecutive с немаскированным SSN
• CustomerListForSupportStaff
• CustomerListForSupportExecutive с общими доходами клиентов
• и т.п.