Создание моделей в DDD, как передать зависимости?

Question

[MIsternik]

Пробую применить DDD к сервису авторизации.
Если пользователь (User) это основная сущность агрегата, то токены это его внутренние сущности и он как-то должен ими управлять и их проверять. Значит ему нужно получать доступ к хранилищу. Помимо хранилища есть необходимость в других функция, например IHashProvider, ITokenProvider для хеширования и проверки пароля, генерации токенов.

Вопрос в том как запихнуть это всё в User незаметно для уровня приложения?
При создании нового пользователя можно сделать фабрику и через рефлекию использовать приватный метод

static User New( string email, string name, string password, IHashProvider hashProvider, IUserRepository repo )

return (User)typeof( User )
    .GetMethod( "New" )
    .Invoke( null, new object[] { email, name, password, _hashProvider, _repository } );

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

Есть какие-то известные практики таких инициализаций сущностей или что в моем понимании DDD не так ?

Answer 1

[Владимир Коротенко]

Что то вы неправильно делаете.
Пользователь себя не создает, это нонсенс, этим занимается специально обученный класс.

if (ModelState.IsValid)
            {
                var user = new AppUser { UserName = Input.Email, Email = Input.Email };
                var result = await _userManager.CreateAsync(user, Input.Password);
                if (result.Succeeded)
                {
                    _logger.LogInformation("User created a new account with password.");

Comments

[MIsternik]

Я как раз и написало что это должна делать фабрика, и прямое создание пользователя недоступно.
Я пока пришел к выводу что управление токенами авторизации все таки не задача пользователя и тогда можно вынести это в сервис.

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

[Владимир Коротенко]

MIsternik, Это не его дело. Нарушение принципа единственной ответственности.

Проведя аналогию: записи в журнале посещений сами себя не делают, их делает вахтер.