Где я могу найти информацию об аутентификации и авторизации в контексте доменного дизайна?

Question

Я пытаюсь сделать что-то вроде DDD (доменного дизайна). И мальчик, я борюсь. Во всех книгах, которые я читаю, аутентификация не имеет значения и не упоминается!

Я написал свою собственную Службу аутентификации и членства, которая отвечает за регистрацию и вход в систему пользователей, создание соленых паролей и т. Д. Я не использую поставщика членства .NET, но использую Аутентификацию по формам.

Я реализовал модель User, которая содержит имя пользователя, E-Mail, PasswordHash, ApprovalStatus и т. Д.

Теперь я думаю, что остальная часть модели предметной области не должна касаться пользователей. У меня есть класс Person, который используется для моделирования людей и связанных с ними данных. Как таковой он может быть использован для моделирования личных данных от пользователей и не пользователей. Объект типа Компания работает с Лицами, а не с Пользователями. И действие назначается человеку, а не пользователю.

Вопрос, как мне связать модель Person с моделью User? Я действительно не хочу ссылки друг на друга в любой из двух моделей. Должен ли я создать некоторую модель отношений с именем PersonUser и создать дополнительную службу, которая извлекает объект person для текущего пользователя, прошедшего проверку подлинности?

Answer 1

Судя по тому, что вы представили, у вас есть пара известных фактов:

1. Каждый пользователь - это человек
2. Не каждый человек является пользователем

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

Теперь я также собираюсь предположить, что у вас есть несколько методов «Fetch» ​​в модели человека ... для извлечения человека по ID, имени, отделу и т. Д. ...

Я бы перегрузил (или создал бы другой) метод выборки, чтобы также получить объект person от пользователя (это может быть либо id, либо foll пользовательский объект).

public IPerson Fetch(IUser user) {}

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

public interface IUser 
{
   ...
   IPerson Person { get; set; }
}

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

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