Агрегаты и объекты значений: Удалить?

Question

В настоящее время я определяю сущности, объекты-значения и агрегаты в системе. Скажем, были определены следующие сущности:

Клиент, CustomerEmail, электронная почта, CustomerAddress, Address, AddressType

, где Клиенты -> Электронные письма - это отношение многие ко многим, как и Клиенты -> Адреса (с типом адреса). Эти отношения представлены объектами отношений CustomerAddress и CustomerEmail.

Первоначально я думал, что это было прямо:

Сущности: Customer, CustomerEmail, CustomerAddress Объекты значения: электронная почта, адрес, AddressType

с Заказчиком, являющимся агрегатным корнем для агрегата, содержащего все сущности и VO, указанные выше.

Проблема, с которой я столкнулся (и это может быть, когда я узнаю о концепциях агрегатов по мере продвижения вперед) Скажем, у вас есть Поставщик, который отражает вышеупомянутую совокупность Клиентов, используя те же объекты значений Address и Email. В этом случае, когда Клиент удален, адрес и электронная почта не должны быть удалены, поскольку Поставщик или даже другой клиент все еще могут ссылаться на них. Я видел много документации, которая предлагает, когда агрегат удаляется, все в пределах границы агрегата удаляется одновременно. Прав ли я, если предположить, что это не относится к объектам-значениям в совокупности (т. Е. Они неизменны ... если бы у нас был цветовой объект зеленый в совокупности транспортных средств ... вы бы не удалили цвет только потому, что автомобиль был удален) или электронная почта и адрес должны быть собственными сущностями (и агрегатами), поскольку два адреса, даже если они могут иметь одинаковые атрибуты, являются фактическими отдельными идентификаторами (т. е. один - это адрес поставщика, а другой - адрес клиента?)

Наконец, если они действительно являются объектами значений, как можно поступить с делом, в котором они должны быть удалены (ни один из поставщиков или клиентов не ссылается на адрес), если на VO можно воздействовать только через их совокупный корень?

Приветствия

Стив

Answer 1

Вы думаете о своем домене в терминах своей базы данных. Это не рекомендуется.

Организация-поставщик, которая отражает вышеуказанную совокупность клиентов

Это говорит о том, что в вашем домене отсутствует концепция. Что это «зеркалирование» означает для вашего эксперта в области? Если между ними действительно есть связь, это должно быть явно смоделировано.

Вы говорите, что «Клиенты -> Электронные письма - это отношения многие ко многим». Для вашего домена имеет значение, что электронная почта используется несколькими клиентами? Если да, то снова вы, вероятно, упускаете понятие. Проверьте, что ваш эксперт по домену должен сказать об этих отношениях. Если на самом деле это не много для многих, а один ко многим, то, возможно, электронная почта является ценным объектом, которым «владеет» объект клиента. Теперь, если клиент владеет электронной почтой или адресом, вы можете удалить его (или действовать по нему) без каких-либо ограничений.

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

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

И в качестве последнего совета - повторное (-re X 100) чтение книги Эрика Эванса обычно помогает:)