Что является лучшей практикой? Тип удостоверения или установка динамического свойства во время выполнения? - PullRequest
0 голосов
/ 17 января 2019

При разработке класса я предполагал, что наличие свойства $id сделает этот класс Entity, а не объектом значения.

У меня также есть метод toArray(), который преобразует объект в ассоциативный массиви этот ответ отправляется на почту и исправляет API.

Теперь у меня есть следующие вопросы:

POST работает, так как я не посылаю id в теле.Но для PATCH это нормально, если я устанавливаю свойство динамически после создания объекта?Например:

$redCircle = new Circle(“red”);
$redCircle->id = 10;
$api->patch($redCircle->toArray());

1 Ответ

0 голосов
/ 17 января 2019

Ваша точка зрения очень техническая, в отличие от DDD.

Вы должны проектировать свои Агрегаты и вложенные сущности в соответствии с бизнес-правилами (инвариантами).

При разработке класса я предполагал, что наличие свойства $ id сделает этот объект Entity, а не объектом значения.

Это не правда. Существуют случаи, когда локальному объекту Value (который поступает из удаленного Aggregate в другом ограниченном контексте) необходимо свойство ID, чтобы поддерживать его в актуальном состоянии (т.е. с помощью фоновых задач). Антикоррупционному слою понадобится это свойство, поэтому причины чисто технические.

POST работает, так как я не отправляю идентификатор в теле. Но хорошо ли для PATCH, если я устанавливаю свойство динамически после создания объекта?

Опять же, это не DDD-представление проблемы. В DDD агрегированные команды выполнения: не просто обновлять свое внутреннее состояние напрямую; это нарушило бы его герметичность.

Но чтобы ответить на ваш вопрос, учитывая, что у вас есть приложение CRUD : для того, чтобы мутировать части сущности, вам необходимо загрузить его из репозитория перед мутацией. Репозиторий установит идентификатор вместе с другими свойствами.

Один из лучших способов найти объекты - использовать API RESTful , поэтому клиенту не нужно будет создавать URL-адреса для операции PATCH.

...