Впровадження DDD: користувачі та дозволи

Я працюю над невеликим додатком, намагаючись зрозуміти принципи доменного дизайну. У разі успіху це може бути пілотним проектом для більшого проекту. Я намагаюся слідкувати за книгою "Впровадження дизайну, керованої доменом" (автор Вон Вернон) і намагаюся реалізувати подібний, простий дискусійний форум. Я також перевірив зразки IDDD на github. У мене є певні труднощі з прийняттям ідентичності та доступу до моєї справи. Дозвольте надати довідкову інформацію:

• Я (сподіваюсь) розумію міркування щодо розділення логіки користувачів та дозволів: це допоміжний домен, і це інший обмежений контекст.
• У основному домені немає користувачів, лише Автори, Модератори тощо. Вони створюються, звертаючись до контексту Identity та Access за допомогою сервісу, а потім переводячи отримані об’єкти Користувача до Модератора.

• Операції з доменом викликаються пов'язаною роллю в якості параметра: наприклад:

  ModeratePost( ..., moderator);

• Метод об’єкта домену перевіряє, чи вказаний примірник Модератора не є нульовим (екземпляр Модератора буде нульовим, якщо користувач запитав з контексту Identity and Access не має ролі Модератора).

• В одному випадку він робить додаткову перевірку перед зміною публікації:

  if (forum.IsModeratedby(moderator))

Мої запитання:

• В останньому випадку хіба проблеми безпеки знову не змішуються в основний домен? Раніше у книгах було зазначено, "з ким можна публікувати тему чи за яких умов це дозволено. Форуму просто потрібно знати, що автор робить це зараз".

• Реалізація на основі ролей у книзі є досить простою: коли модератор є основним доменом, він намагається перетворити поточний користувальницький ідентифікатор в екземпляр Модератора або в автора, коли це потребує. Сервіс відповість відповідним екземпляром або нулем, якщо користувач не має необхідної ролі. Однак я не бачу, як я міг би адаптувати це до більш складної моделі безпеки; наш нинішній проект, над яким я пілотую, має досить складну модель з групами, ACL тощо.

Навіть із правилами, які не дуже складні, як-от: "Публікацію слід редагувати лише її власником чи редактором", такий підхід здається порушеним, або, принаймні, я не бачу правильного способу його виконання.

Запитуючи контекст Identity and Access для екземпляра OwnerOrEditor, це не так, і я закінчую все більшою кількістю класів, пов’язаних із безпекою в основній області. Крім того, мені потрібно було б передати не лише userId, а ідентифікатор захищеного ресурсу (ідентифікатор повідомлення, форуму тощо) до контексту безпеки, який, мабуть, не повинен перейматися цими речами (чи правильно це? )

Перетягнувши дозволи на основний домен і перевіривши їх у методах об’єктів домену або в службах, я б закінчився на квадратному: змішування проблем безпеки з доменом.

Я десь читав (і я з цим погоджуюся), що ці речі, пов'язані з дозволом, не повинні бути частиною основного домену, якщо тільки безпека та дозволи не є основним доменом. Чи виправдовує таке просте правило, як наведене вище, що робить безпеку частиною основного домену?

Іноді важко відрізнити між реальними правилами контролю доступу та інваріантами доменів, які обмежують обмеження на контролі доступу.

Тим більше, правила, які залежать від даних, доступних лише далеко в ході певної логіки домену, не можуть бути легко витягнутими з домену. Зазвичай контроль доступу викликається до або після операції над доменом, але не під час.

assert (forum.IsModeratedBy(moderator))Приклад Вуна Вернона, ймовірно, мав бути поза Доменом, але це не завжди можливо.

Мені потрібно передати не лише userId, а ідентифікатор захищеного ресурсу (ідентифікатор повідомлення, форуму тощо) до контексту безпеки, який, ймовірно, не повинен перейматися цими речами (чи правильно це?)

Якщо є БЦ безпеки і ви хочете, щоб він обробляв цю логіку, він не повинен детально знати, що таке Форум, але:

• Він може просто знати такі поняття, як "модерується", і надавати або забороняти права доступу відповідно.
• Ви можете мати логіку адаптера, яка підписує події Core Domain і переводить їх у прості пари значень ключів (ресурс, дозволені користувачі) для БЦ безпеки для зберігання та використання.

Автентифікація та авторизація є поганим прикладом для DDD.

Жодне з цих речей не є частиною домену, якщо ваша компанія не створює продукти безпеки.

Вимога компанії або домену є або повинна бути "мені потрібна автентифікація на основі ролі"

Потім ви перевіряєте роль перед викликом функції домену.

Якщо у вас є складні вимоги, такі як "Я можу редагувати власні публікації, але не інші", переконайтеся, що ваш домен відокремлює функцію редагування, EditOwnPost()і EditOthersPost()щоб у вас була проста функція відображення ролей

Ви також можете розділити свою функціональність на об’єкти домену, такі як, Poster.EditPost()і Moderator.EditPost()це більш підхід OOP, хоча ваш вибір може залежати від того, чи буде ваш метод у службі домену або об’єкт домену.

Однак ви вирішите відокремити код, Рольове відображення відбуватиметься поза Доменом. так, наприклад, якщо у вас є контролер webapi:

PostController : ApiController
{
    [Authorize(Roles = "User")]
    public void EditOwnPost(string postId, string newContent)
    {
        this.postDomainService.EditOwnPost(postId, string newContent);
    }

    [Authorize(Roles = "Moderator")]
    public void EditOtherPost(string postId, string newContent)
    {
        this.postDomainService.EditOtherPost(postId, string newContent);
    }
}

Як ви бачите, хоча відображення ролей робиться на хостинговому шарі, складна логіка того, що являє собою редагування вашої власної чи іншої публікації, є частиною домену.

Домен визнає різницю дій, але вимога безпеки полягає лише в тому, що "функціональність може бути обмежена ролями" .

Це, можливо, зрозуміліше з розділенням об'єктів домену, але по суті ви перевіряєте метод, який будує об'єкт, а не метод, який викликає сервісний метод. Ваша вимога, якщо ви все ще хочете озвучити це як частину домену, стане "лише модератори можуть сконструювати об'єкт модератора"