CQRS применяет сквозные проблемы, такие как безопасность - PullRequest
5 голосов
/ 26 января 2012

Предположим, у меня сложная система, где есть большие деревья людей.Простыми мыслями являются отношения между сотрудниками и менеджером, многие сотрудники подчиняются одному менеджеру.Теперь, помимо менеджера, есть вспомогательный персонал, который способен действовать от имени менеджера, может манипулировать сотрудниками менеджеров.

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

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

Где будет этот запрос?До создания сообщения «изменить сотрудника»?

Если данные предварительно проверены перед созданием сообщения, в согласованной в конечном итоге системе предположим, что до обработки сообщения «Редактировать сотрудника» произошло отдельное действие, котороеудалил бы полномочия пользователя на выполнение действия «изменить сотрудника».Если обработчик команд не проверяет проблемы безопасности этого сообщения, сообщение все равно будет успешно выполнено, даже если у пользователя больше нет прав на его выполнение.

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

Какой подход (ы) лучше всего использовать при решении этих и других аналогичных сквозных проблем при использовании CQRS?

Ответы [ 2 ]

5 голосов
/ 26 января 2012

Во-первых, я согласен с комментарием @ Yahia, что нет общего ответа.С учетом вышесказанного, вот как я подхожу к этому.

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

Итак, с точки зрения псевдокода, вот мой подход к редактированию сотрудника:

Контроллер

[HttpPost]
ActionResult Edit(Employee emp){

  //get employee org information from _employeeRepository
  //validate if _loggedInUserID is able to edit emp.ID

  if(isValid) {
    //construct command
    _commandService.EnqueueCommand(new EditEmployee(emp.ID, emp.Name, emp.Salary));
  } else {
    return View("PermissionError");
  }

  return Redirect("EmployeeProperties");
}

Итак, моя командная служба берет команду и направляет ее к соответствующему AR в моем домене, который будет Employee.

Домен Employee

protected void EditEmployee(userID, employeeID, employeeName, salary){
  //get employee org information from _employeeRepository
  //validate if userID is able to edit employeeID

  if(isValid) {
    //apply event
    ApplyEvent(new EmployeeEdited(userID, employeeID, employeeName, salary));
  }
}

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

Так что я надеюсь, что это поможет при подходе к этому сценарию.Дайте мне знать, если есть вопросы, и я уточню в своем ответе.

Надеюсь, это поможет.Удачи!

3 голосов
/ 26 января 2012

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

...