php - DDD - 聚合 - 真的应该避免使用 setter/getter 吗？

Question

早上好，

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

让我们想象以下 用户 应收账款:

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

现在让我们想象以下 用户库 界面:

namespace vendor\Domain;

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

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

现在，让我们想象以下 内存中 实现 用户库 :

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() setter/getter 。真的很糟糕吗？是否允许对必须访问的属性使用 getter？我应该简单地认为 getEmail() getter 具有商业意义，在哪种情况下，它是完全有效的？

Answer 1

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

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

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

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