Рекомендации для принятия решения о том, когда доменная роль должна быть явно смоделирована

Я ищу некоторые рекомендации относительно того, когда нужно явно моделировать роль в модели предметной области.

Я объясню свою текущую позицию с помощью примера здесь.

Допустим, мы строим систему здравоохранения, а бизнес-требование гласит

«Оперировать могут только врачи со стажем от 3 лет и определенной квалификацией»

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

docter.performSurgery()

По сути, все врачи разные

Этот метод, вероятно, проверит, выполнены ли предварительные условия

Поэтому в приведенных выше случаях я буду моделировать роль явно.

Теперь давайте рассмотрим альтернативный сценарий.

Только администратор может одобрить перевод средств

В приведенном выше случае я не считаю необходимым моделировать эту роль в домене, поскольку в моем домене нет правил, отличающих одного администратора от другого.

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

approveTransfer(), вызываемый на уровне приложения, вызывается только в том случае, если текущий вошедший в систему пользователь имеет разрешение ADMIN.

Таким образом, "модель предметной области", под которой я подразумеваю такие классы, как класс Account, не знает об этом правиле, это кодифицировано на прикладном уровне либо через AOP, либо, возможно, через класс AccountService или тому подобное.

Что говорят об этом мудрецы? :)


domain-driven-design
person Sudarshan    schedule 18.10.2014    source источник
comment
С точки зрения используемого языка, и простите за следующее, поскольку я не знаю, как структурированы агрегаты, но не будет ли это doctor.scheduleSurgery(date)? Судя по вашему сообщению и функции PerformSurgery, система выполняет резку!   -  person morleyc    schedule 19.10.2014
comment
Я согласен, мы могли бы обсудить используемый язык, поскольку он не относится к конкретному варианту использования, однако основное внимание в вопросе было уделено тому, когда необходимо моделировать класс доктора (роль домена), а когда нет,   -  person Sudarshan    schedule 21.10.2014

Ответы (1)


arrow_upward
0
arrow_downward

При проектировании агрегатов я всегда задаю себе важный вопрос.

  • Какова граница согласованности для процесса, который я пытаюсь смоделировать?

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

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

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

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

Отдельная ситуация может возникнуть для аутентификации пользователя. У вас может быть ограниченный контекст с моделью Customer, но детали разрешений, аутентификации и ролей настолько обширны, что для работы с ними требуется совершенно отдельная система. В этом случае вы можете создать отдельный ограниченный контекст для User Roles and Permission и связать два ограниченных контекста. В этом сценарии у вас может быть служба домена, которая занимается связью между ними. Вызовите Customer корень с операцией и передайте в службу домена какое-то намерение, раскрывающее двойную отправку, и позвольте службе домена решить, проходит ли эта операция или нет. Однако в этом сценарии ответственность за аутентификацию пользователя лежит вовсе не на Customer. Customer просто все равно (потому что он сам не может гарантировать транзакцию), и User Auth and Roles решает, что делать.

Источник: Реализация дизайна, ориентированного на предметную область - Вон Вернон

Правильно спроектированный Агрегат — это агрегат, который можно модифицировать любым способом, требуемым для бизнеса, с его инвариантами, полностью согласованными в рамках одной транзакции. И правильно спроектированный Bounded Context изменяет только один экземпляр Aggregate на транзакцию во всех случаях. Более того, мы не можем правильно рассуждать об Агрегатном дизайне без применения транзакционного анализа.

person Seph    schedule 28.04.2015