Ваша точка зрения очень техническая, в отличие от DDD.
Вы должны проектировать свои Агрегаты и вложенные сущности в соответствии с бизнес-правилами (инвариантами).
При разработке класса я предполагал, что наличие свойства $ id сделает этот объект Entity, а не объектом значения.
Это не правда. Существуют случаи, когда локальному объекту Value (который поступает из удаленного Aggregate в другом ограниченном контексте) необходимо свойство ID, чтобы поддерживать его в актуальном состоянии (т.е. с помощью фоновых задач). Антикоррупционному слою понадобится это свойство, поэтому причины чисто технические.
POST работает, так как я не отправляю идентификатор в теле. Но хорошо ли для PATCH, если я устанавливаю свойство динамически после создания объекта?
Опять же, это не DDD-представление проблемы. В DDD агрегированные команды выполнения: не просто обновлять свое внутреннее состояние напрямую; это нарушило бы его герметичность.
Но чтобы ответить на ваш вопрос, учитывая, что у вас есть приложение CRUD : для того, чтобы мутировать части сущности, вам необходимо загрузить его из репозитория перед мутацией. Репозиторий установит идентификатор вместе с другими свойствами.
Один из лучших способов найти объекты - использовать API RESTful , поэтому клиенту не нужно будет создавать URL-адреса для операции PATCH.