DDD：从聚合根访问存储库是否被认为是不好的做法？

Question

I've read that accessing repository from aggregate root considered bad practice. If it is, than consider following example:

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?
     ...
   }
}

How will I persist username to database if I don't have access to repository from aggregate root?

I see it like this:

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); 
    }
}

Or I've missed something in DDD concepts?

Answer 1

How will I persist username to database if I don't have access to repository from aggregate root?

Current practices normally handle I/O in the application component, rather than in the domain model.

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

Recommended reading: Vladimir Khorikov on domain model isolation.

Answer 2

Just to extend a little the answer given by @VoiceOfUnreason (which is totally right) here a quick explanation on why injecting repositories via constructor to Aggregate Roots is not advisable:

The repository should depend on the object it returns, not the other way around. The reason for this is that your "domain object" (more on that later) can exist (and should be testable) without being loaded or saved (that is, having a dependency on a repository).

Basically your design says that in order to have an user, you need to provide a MySQL/Mongo/XXX instance connection which is an infrastructure detail. Your domain should not know anything about how it is persisted. Your domain knows about the behavior, invariants, business rules and so on.

These concepts just help you to create code easier to maintain as well as help you to apply best practices such as SRP (Single Responsibility Principle).