как мы можем моделировать поведение различных типов пользователей в DDD?

Я нахожусь в ситуации, когда я должен смоделировать (в домене) требование, где пользователь может быть администратором счетов и системным администратором и < strong>сотрудник.

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

Сотрудник, Системный администратор и Администратор счетов — это разные роли пользователя. Какие-либо предложения?

Обновление:

Дополнительная информация: Учитывая, что Коммуникация сотрудников и Комбинация оплаты счетов и Компания System BC — это три разных ограниченных контекста, что может быть идеальный способ справиться с приведенным выше сценарием?


domain-driven-design domain-model
person inN0Cent    schedule 01.10.2014    source источник
comment
Вы не дали подробностей, но мне кажется, что эти три роли на самом деле находятся в трех разных ограниченных контекстах (счет, система и сотрудник кажутся мне совершенно не связанными), и поэтому вам, вероятно, лучше моделировать их полностью независимыми. , даже если это означает некоторое дублирование кода.   -  person Alexander Langer    schedule 02.10.2014
comment
да, это именно так, они относятся к разным бизнес-контекстам, и, возможно, мой способ мышления неверен, я все еще думаю о способе данных... т. е. таблицу пользователей можно повторно использовать для всех трех ролей, имея идентификатор роли может быть, я могу повторно использовать объекты таким же образом, что, возможно, неправильно при моделировании предметной области.   -  person inN0Cent    schedule 02.10.2014
comment
Общая рекомендация заключается в том, что вам следует избегать повторного использования любой формы между BC.   -  person Alexander Langer    schedule 02.10.2014

Ответы (1)


arrow_upward
4
arrow_downward

Возможно, вы смешиваете ограниченные понятия, и наследование, вероятно, тоже не помогает :)

Обычно используется Управление идентификацией и доступом BC. Здесь мы можем найти User, Permission и Role.

Тогда можно иметь BC Employee или Human Resources. Здесь могут существовать такие понятия, как Employee и Manager.

Так что это может помочь разделить эти понятия.

Когда регистрируется новый сотрудник, HR BC может опубликовать событие EmployeeRegistered, используя служебную шину, на которую подписывается I & AC BC для регистрации нового сотрудника. пользователь.

Надеюсь, это поможет.

person Eben Roux    schedule 02.10.2014
comment
хм, это выглядит довольно изящным решением, но если у меня есть три бизнес-контекста, то есть Bill, System и Employee, является ли I & AC BC прослушиванием событий, опубликованных этими BC, идеальным способом моделирования данной ситуации? - person inN0Cent; 02.10.2014
comment
Наличие отдельных бизнес-контентов с архитектурой, управляемой событиями, вполне может облегчить вашу жизнь. Моделирование может быть сложным, и ваша модель в любом конкретном BC может время от времени нуждаться в некотором переосмыслении, но в какой-то момент вы склонны находить хороший баланс и что-то, что кажется удобным. Попутно это означает, что изменения в сообщениях вполне вероятны. Так что, учитывая тот факт, что я не являюсь экспертом в вашей области, мой гипотетический случай может быть не идеальным, но он, безусловно, является отправной точкой :) - person Eben Roux; 03.10.2014