DDD - проверка уникального ограничения

В DDD вы никогда не должны позволять своим сущностям вводить недопустимое состояние. Как говорится, как вы обрабатываете проверку уникального ограничения?

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

Вы не можете просто использовать сеттер... объект может ввести недопустимое состояние - вы должны проверить его на базе данных.

Как вы справляетесь с этим сценарием в веб-среде?

Ответы

Ответ 1

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

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

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