DDD: доступ к репозиторию из совокупного корня считается плохой практикой?

Question

Я читал, что доступ к репозиторию из совокупного корня считается плохой практикой. Если, чем рассмотреть следующий пример:

class User { 
    private String username; 
    public void changeUsername(String newUsrname) { 
    // How will I persist username to database if I don't have access to repository from aggregate root? 
    ... 
    } 
} 

Как будет сохраняться имя пользователя в базе данных, если у меня нет доступа к репозиторию от совокупного корня?

Я вижу это так:

class User { 
    private String username; 
    private UserRepository userRepository; 
    public User(UserRepository userRepository) { 
     this.userRepository = userRepository; 
    } 

    public void changeUserName(String newUsername) { 
     this.username = newUserName; 
     userRepository.save(this); 
    } 
} 

Или я что-то пропустил в понятиях DDD?

Answer 1

Как я буду сохранять имя пользователя в базе данных, если у меня нет доступа к репозиторию из агрегированного корня?

Текущая практика обычно обрабатывает ввод-вывод в компоненте приложения, а не в модели домена.

Application { 
    void when(ChangeUserName command) { 
     User user = this.userRepository.getUserById(command.userId); 
     user.changeName(command.name); 
     this.userRepository.save(user); 
    } 
} 

Рекомендованное чтение: Vladimir Khorikov по изоляции модели домена.

Answer 2

Просто продлить немного ответ дается @VoiceOfUnreason (что совершенно верно) здесь краткое объяснение о том, почему инъекционных репозиториях через конструктор, чтобы агрегировать корни не рекомендуется:

Хранилище должно зависеть от объекта, возвращается, а не наоборот. Причина этого в том, что ваш «объект домена» (подробнее об этом позже) может существовать (и должен быть проверен) без загрузки или сохранения (т. Е. Наличия зависимости от репозитория).

В принципе, ваш дизайн говорит, что для того, чтобы иметь пользователя, вам необходимо предоставить подключение к экземпляру MySQL/Mongo/XXX, которое является детальностью инфраструктуры. Ваш домен не должен знать ничего о том, как он сохраняется. Ваш домен знает о поведении, инвариантах, бизнес-правилах и т. Д.

Эти концепции просто помогут вам создать код, который проще поддерживать, а также помогут вам применять лучшие практики, такие как SRP (принцип единой ответственности).