DDD — Совокупность — Следует ли действительно избегать добытчиков?

Доброе утро,

Я много раз читал, что в AR нужно избегать как сеттеров, так и геттеров. Хотя я могу понять причину для сеттеров, я немного не согласен с геттерами, когда они явно являются частью бизнеса.

Давайте представим следующее пользователь 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;
...
}

В основном здесь, у меня есть некоторые искатели, которые позволяют получить пользователь по его идентификатору, имени пользователя или адресу электронной почты.

Теперь давайте представим следующее в памяти реализация этого 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 () добытчик. Это действительно плохо? Разрешено иметь геттеры для свойств, которые должны быть доступны? Должен ли я просто учитывать, что getEmail () Геттер имеет деловое значение, в каком случае он совершенно действителен?

0

Решение

Геттер в порядке. Случай «не писать геттеры» состоит в том, чтобы избежать раскрытия внутреннего состояния вне агрегата: когда ваши сервисы берут агрегат, извлекают его состояние и принимают какое-то решение на основе этого. Это то, что вы хотите избежать.

Вы можете следовать принципам Закона Деметры и стремиться к этому. Строго избегайте добытчика, но помните о них.

Иметь getId или же getUsername отлично в порядке.
Иметь getCollectionВид метода, который возвращает изменчивую коллекцию, отсутствует. Агрегат теряет контроль над внутренними деталями, деталями реализации. Когда вы выставляете что-то вроде getFriends()ваши службы могут вызывать его, добавлять или удалять вещи вне агрегата, и вы в основном теряете способность реорганизовывать агрегат, не нарушая ничего. addFriend() а также deleteFriend() в этом случае решит это. И если getFriends() возвращает неизменный коллекция, это тоже хорошо.

Не пишите добытчики это не жесткое правило, старайтесь не показывать слишком много состояния вне совокупности, но не излишне усложняйте свою жизнь, не имея любой добытчики вообще. Используйте их, если это имеет смысл.

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]