DDD - проверка уникального ограничения - PullRequest
12 голосов
/ 18 апреля 2010

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

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

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

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

Ответы [ 2 ]

11 голосов
/ 18 апреля 2010

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

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

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

0 голосов
/ 19 апреля 2018

В поисках ответа на ваш вопрос я наткнулся на эту статью: https://thinkbeforecoding.com/post/2009/10/28/Uniqueness-validation-in-CQRS-Architecture.

По сути: ищите область уникальности и сохраняйте достоверный список уникальных значений в сводном корне, представляющем эту область.

Например, учитывая вариант использования «при регистрации нового пользователя, запрашиваемый логин должен быть уникальным», это может быть: логин должен быть уникальным для арендатора (или компании, или страны, ...) Сохраните информацию о заданных именах входа в списке в сводном корне, представляющем владельца.

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

...