Допустимость метода объекта домена в зависимости от контекста или вызывающего - PullRequest
0 голосов
/ 29 мая 2019

В настоящее время я читаю о DDD, и у меня возникла проблема с реализацией определенной проверки.

Сценарий:

У меня есть объект Group, содержащийсписок Member с, который в свою очередь состоит из User и MemberState (Member, Admin).У сущности есть метод MakeAdmin(User user), который превращает члена в администратора.

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

Я имею в виду три возможных реализации, с некоторыми оговорками.

Вариант 1

Group Единица получает зависимость IUserContext, внедренную через конструкторчтобы получить текущего пользователя.При этом объект может проверить, является ли текущий пользователь администратором и может ли он переключать состояние члена.Предостережение: мне не нравится, что в сущность домена добавлена ​​такая зависимость, и я не думаю, что это правильно в представлении DDD.

Вариант 2

Метод MakeAdmin() получает дополнительный параметр, который превращает его в MakeAdmin(User user, User currentUser).Это устраняет требование зависимости IUserContext в сущности.Предостережение: я не уверен, правильно ли вообще, что сущность проверяет это правило, потому что это на самом деле не инвариант сущности.

Вариант 3

Подтвердите это правило в службе приложений и вызывайте MakeAdmin(User user), только если проверка пройдена.Предостережение: я считаю, что домен правил специфичен, поэтому считаю неправильным помещать его на прикладной уровень.

Так что будет лучшим вариантом, или есть какой-то совершенно другой вариант?

1 Ответ

0 голосов
/ 29 мая 2019

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

Это действительно для любой функциональности домена. Домен не должен заботиться о том, может ли действие выполняться или нет на основе авторизации, а только о проблемах домена. Если это действие авторизации является проблемой домена в конкретном Identity & Access Control ограниченном контексте, это будет иметь смысл, но вы не столкнетесь с этим слишком часто.

...