DDD - Проверка ограничения на уникальность данных
В DDD Вы никогда не должны позволять своим объектам ввести недопустимое состояние. Однако как Вы обрабатываете проверку ограничения на уникальность данных?
Создание объекта не является настоящей проблемой. Но позвольте, говорят, что у Вас есть объект, который должен иметь уникальное имя и существует тысяча экземпляров этого типа объекта - они не находятся в памяти, но сохранены в базе данных. Теперь позвольте, говорят, что Вы хотите переименовать экземпляр.
Вы не можете только использовать метод set... объект мог ввести недопустимое состояние - необходимо проверить против базы данных.
Как Вы обрабатываете этот сценарий в веб-среде?
1 ответ
Ограничение уникальности может быть сокращено до исключения постоянства, а не рассматриваться как «недопустимое состояние». Это не недопустимое состояние, пока объект не будет сохранен. Уникальность имеет смысл только в контексте настойчивости. На самом деле вы можете поместить такое правило в свой механизм проверки, чтобы снизить вероятность этой ошибки, но в любой реальной многопользовательской системе вы не можете гарантировать уникальность, пока успешная единица работы не завершит действие сохранения.
Таким образом, вы можете захотеть это в вашем механизме проверки, но вы должны обеспечить это на своем уровне сохранения.
Я вообще поклонник DDD как методологии, но думаю, что «не позволять объектам переходить в недопустимые состояния» может потребовать некоторых извилистых абстракций. В веб-приложении наличие отдельной «модели представления» является одним из возможных решений в качестве промежуточного уровня перед сохранением, но я обычно не делаю этого, пока не убедился, что это причинит мне меньше боли, чем более простая альтернатива.