DDD - 聚合 - 真的应该避免使用吸气剂吗？

Question

早上好，

我已经读过很多次了，在 AR 中应该避免使用 setter 和 getter。虽然我可以理解使用 setter 的原因，但当它们显然是业务的一部分时，我对 getter 有点不同意。

让我们想象以下用户AR：

namespace vendor\Domain\Model;

class User
{
    private $userId;
    private $username;
    private $password;
    private $email;

    static public register(...): User { ... } // Ubiquitous Language
    public function unregister(...) { ... } // Ubiquitous Language
    public function changePassword(...) { ... } // Ubiquitous Language
    public function changeEmail(...) { ... } // Ubiquitous Language
    public function getAggregateId(): UserId { ... } // A getter
    public function getUsername(): UserName { ... } // A getter
    public function getEmail(): UserEmail { ... } // A getter
    ...
}

现在让我们想象以下UserRepository接口：

namespace vendor\Domain;

interface UserRepository
{
    public function userOfId(UserId $userId):? User;
    public function userOfname(UserName $userName):? User;
    public function userOfEmail(UserEmail $userEmail):? User;
    ...
}

基本上在这里，我有一些查找器可以通过其 ID、用户名或电子邮件地址检索用户。

现在，让我们想象一下UserRepository的以下内存实现：

namespace vendor\Infrastructure\Persistence;

use vendor\Domain\UserRepository;

class InMemoryUserRepository implements UserRepository
{
    /** User[] */
    private $users;

    public function userOfId(UserId $userId):? User
    {
        if(!isset($this->users[$userId->tostring()]) {
            return null;
        }

        $this->users[$userId->tostring()];
    }

    public function userOfEmail(UserEmail $userEmail):? User
    {
        foreach($users as $user) {
            if($user->getEmail()->sameValueAs($userEmail) {
                return $user;
            }
        }

        return null;
    }
    ...
}

如您所见，在内存中的实现中，我需要通过电子邮件过滤用户，访问他们的电子邮件属性。这必然意味着用户AR 需要提供getEmail() 获取器。真的很糟糕吗？是否允许对必须访问的属性使用 getter？我应该简单地认为getEmail() 获取器具有商业意义，在这种情况下，它是完全有效的吗？

Answer 1

吸气剂很好。“不写 getter”的情况是为了避免在聚合之外暴露内部状态：当您的服务获取聚合时，获取其状态，并基于此做出一些决定。这就是你想要避免的。

你可以遵循迪米特法则的指导方针，并以此为目标。不要严格避免 getter，但要注意它们。

有一个getIdorgetUsername完全没问题。有一种getCollection返回可变集合的方法不是。聚合失去了对内部细节和实现细节的控制。当你暴露类似 的东西时getFriends()，你的服务可以调用它，添加或删除聚合之外的东西，你基本上失去了在不破坏一切的情况下重构聚合的能力。一个addFriend()和deleteFriend()在这种情况下，将解决这个问题。如果getFriends()返回一个不可变的集合，也没关系。

不要写 getter不是一个硬性规则，尽量不要在聚合之外暴露太多状态，但不要因为没有任何getter而不必要地使你的生活复杂化。如果有意义，请使用它们。