Домен Управляемый Дизайн внедряет агрегаты

Question

Я читал о создании и обязанностях агрегатов, и у меня есть сомнения, как правильно их реализовать.Предположим, что у нас есть контекст внутри, есть 2 сущности.Один - это Компания, а второй - Пользователь.Бизнес-правила находятся в компании, что означает, что они должны стать совокупным корнем.Компании мы можем назначить только 3 пользователей и не можем назначить Пользователя, когда Comapny имеет статус «заблокирован».Пользователь также имеет возможность войти, используя emial и пароль.Имея это в виду, что каждое действие над сущностью пользователя должно вызываться через общий корень, а у пользователя не должно быть своего собственного репозитория.Как сделать действие входа в систему на Пользователя, когда мы не можем сделать это напрямую без корня компании?Мы не можем вызвать пользователя из совокупности.Как найти пользователя с указанным адресом электронной почты и паролем?Извлечение всех Агрегатов и перебор их Пользователей неэффективно, и я думаю, что это не очень хорошая идея.Спасибо за помощь.

Answer 1

Аутентификация обычно не является частью домена (в 99% всех случаев использования), а только частью инфраструктуры.

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

Так что для регистрации проблем у вас есть наши пользователи с именем пользователя и паролем, которые служат для аутентификации.У этих пользователей есть идентификатор (числовой, строковый или guid).

Ваш Employee или Persons объект / агрегат (или то, что вы назвали, зависит от вашего домена, точный термин зависит от компании к компании).- вездесущий язык) содержит только те данные, которые принадлежат человеку (но не информацию, относящуюся к идентификации).

Затем вы можете подключить сотрудников к пользователям (либо с помощью идентификатора сотрудника, который будет идентификатором пользователей, используемых для входа в систему, дополнительного поля или с помощью таблицы поиска 1: 1 или 1: n.

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

Answer 2

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