Следует ли игнорировать уникальность при принятии решения, является ли объект сущностью или значением?

Question

Считается ли уникальность постоянной проблемой в DDD?

Причина, по которой я спрашиваю, заключается в том, что у меня есть Customer объект в контексте цитирования заказа.например, заказ для клиента, и клиент должен заплатить определенную ставку.

Технически, я не позволю клиенту иметь тот же код или имя, что и у другого.Это означает, что если у меня есть два Customer объекта с одинаковым кодом и именем, они всегда будут обрабатываться одинаково, как объект значения.

Но инстинктивно Customer ощущается как сущность.Неужели это уникальное ограничение выбивает меня из колеи или я прав, считая, что это объект значения?

Контекст цитирования заказа также позволяет добавлять / редактировать / удалять клиентов со страницы администратора.Может ли это быть вызвано путаницей?Должны ли страницы администратора быть частью другого контекста, где Customer является сущностью, а контекст цитирования заказа будет использовать Customer в качестве объекта значения?

Answer 1

Это отличный вопрос, и вы уже частично на него ответили, ваш клиент является организацией в вашем ограниченном контексте администрирования.

Хорошее эмпирическое правило, чтобы решить, является ли объект сущностью, - это думать с концепцией идентичности. Если для вашего объекта требуется личность, которая останется неизменной с течением времени, даже если имя человека или контактные данные могут измениться, то это скорее всего сущность.

Однако, определив эту концепцию, вы можете иметь CustomerId, который состоит из инварианта с точки зрения бизнеса, в вашем случае - кода и имени.

Этот CustomerId не является техническим идентификатором, это служебный идентификатор, и идентификатором вашей организации будет этот идентификатор. В ограниченном контексте цитирования Заказа вы можете затем ссылаться на своего Клиента, используя тот же объект (возможно, определенный где-то в совместно используемом контексте, или дублируя код: в DDD вполне нормально дублировать некоторый код для обеспечения слабой связи).