Что является лучшей практикой? Тип удостоверения или установка динамического свойства во время выполнения?
Для ваших данных, вероятно, лучше использовать барьер вместо гистограммы. Проверьте этот код:
from collections import Counter
import numpy as np
import matplotlib.pyplot as plt
labels, values = zip(*Counter(['A','B','A','C','A','A']).items())
indexes = np.arange(len(labels))
width = 1
plt.bar(indexes, values, width)
plt.xticks(indexes + width * 0.5, labels)
plt.show()
Результат: 
[/g0]
1 ответ
Ваша точка зрения очень техническая, в отличие от DDD.
Вы должны проектировать свои Агрегаты и вложенные сущности в соответствии с бизнес-правилами (инвариантами).
При разработке класса я предполагал, что наличие свойства $ id сделает этот объект Entity, а не объектом значения.
Это не так. Существуют случаи, когда локальному объекту Value (который поступает из удаленного Aggregate в другом ограниченном контексте) необходимо свойство ID, чтобы поддерживать его в актуальном состоянии (т.е. с помощью фоновых задач). Антикоррупционному слою понадобится это свойство, поэтому причины носят чисто технический характер.
POST работает, так как я не отправляю идентификатор в теле. Но хорошо ли для PATCH, если я устанавливаю свойство динамически после создания объекта?
Опять же, это не DDD-представление проблемы. В DDD агрегированные команды выполнения: не просто обновлять свое внутреннее состояние напрямую; это нарушило бы его герметичность.
Но чтобы ответить на ваш вопрос, учитывая, что у вас есть приложение CRUD : для того, чтобы мутировать части сущности, вам необходимо загрузить его из репозитория до мутации. Репозиторий установит идентификатор вместе с другими свойствами.
Один из лучших способов определить местонахождение сущностей - это использовать RESTful API, поэтому клиенту не нужно будет создавать URL-адреса для операции PATCH.