Где я должен проверить уникальность в архитектуре DDD

В моей доменной модели у меня есть совокупный корень клиента. Мое бизнес-правило: -> я не могу добавить нового клиента с тем же именем, фамилией и адресом электронной почты. Где лучше всего провести такую ​​проверку?

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

Итак, последний вариант, который я вижу, — это создать класс CustomerService и разместить здесь такую ​​проверку.

У вас есть другие рекомендации? Я уже прочитал много других сообщений, но они не дают четкого ответа... Спасибо!!


domain-driven-design ddd-service ddd-repositories
person Simon    schedule 20.01.2019    source источник
comment
Я голосую за то, чтобы закрыть этот вопрос как не по теме, потому что это скорее концептуальный вопрос, который относится к softwareengineering.stackexchange.com.   -  person entpnerd    schedule 21.01.2019

Ответы (1)


arrow_upward
1
arrow_downward

Общий термин для описываемой вами проблемы: проверка.

Если для бизнеса допустимо, чтобы инвариант нарушался в течение коротких периодов времени, то вы устанавливаете процесс, который отслеживает все агрегаты ваших клиентов в поисках конфликтов и уведомляет процесс исправления, если таковой обнаруживается. Вы можете уменьшить (но не устранить) риск коллизий, включив проверку предыдущих записей в свою бизнес-логику; все еще существует вероятность того, что ограничение будет нарушено в гонке данных.

Если это неприемлемо (возможно, юридические или финансовые последствия слишком серьезны), тогда все становится сложнее.

Один из ответов, который иногда будет работать, состоит в том, чтобы взять значения, которые должны быть уникальными, и использовать их для создания уникального идентификатора агрегата. К сожалению, имя, фамилия и адрес электронной почты недостаточно стабильны, чтобы быть хорошими кандидатами для такого подхода (что произойдет, если ваш клиент изменит свой адрес электронной почты? или свое официальное имя?)

Это оставляет блокировку всего набора клиентов, когда вы вносите изменения в одного из них. Это может быть так же просто, как заставить любой процесс, который собирается изменить клиента, получить общую блокировку, или поместить всех клиентов в один агрегат, или запрограммировать ограничение в вашем хранилище (подумайте об ограничениях в СУБД).

person VoiceOfUnreason    schedule 20.01.2019