Или логику аутентификации нельзя объединять в класс пользователя. Хорошо. А что тогда можно?
Добавление ролей?
await user.AddRole(role);
await user.AddRoles(role1, role2, role3);
-> user.Roles => [role, role1, role2, role3]
Ну, терпимо... Типа, можно одному пользователю сразу несколько ролей назначить.
Теперь аналогичное, но наоборот. В одну роль несколько пользователей. Хм...
await role.AddUsers(user1, user2, user3);
-> role.Users => [user1, user2. user3]
и, при этому
-> user1.Roles => [role]
Блин, чересчур сильная связность. Любое изменение role в одном месте (название поменяли), ведёт к необходимости отследить все активные экземпляры User и поменять в коллекции ролей ту, которая изменилась. И это только в случае, если участвуют два связанных между собой класса - User и Role. В enterprise всякие сущности имеют немного сильно больше связей между собой.
Ладно, через свойства нельзя. Можно, но видим, что есть проблемы. Давайте через методы.
await user.GetRoles() => [role]
await role.GetUsers() => [user1, user2, user3]
Ну так вроде уже что-то. Но, опять, это только для случая двух связанных классов. Добавим немного ещё.
await company.GetUsers() => [user1, user2, user3]
await department1.GetUsers() => [user2, user3]
await department2.GetUsers() => [user1, user3]
await document1.GetAuthors() => [user3]
2. мы можем добавить и роль пользователю, и пользователей в роль, здесь возможны оба варианта, НО для избежания сильной связности стоит правильно формировать связи между сущностями, у тебя пользователь и роль это две отдельные сущности, достаточно в пользователе хранить список айдишников ролей и это всё из ролей что потребуется трекать в пользователе
3. пример с компаниями и департаментами вполне себе валидный, хочешь получить пользователей, добавляй соответствующий метод, или обобщай это всё отдельный класс/интерфейс
