Блог

У меня есть пара вопросов, касающихся взаимосвязи между ссылками между двумя совокупными корнями в модели DDD. Обратитесь к типичной модели клиента / заказа, представленной на диаграмме ниже.

Во-первых, должны ли ссылки между фактической объектной реализацией агрегатов всегда выполняться через значения идентификаторов, а не ссылки на объекты? Например, если я хочу получить подробную информацию о клиенте заказа, мне нужно будет взять CustomerID и передать его в ICustomerRepository, чтобы получить клиента, а не настраивать объект Order для прямого возврата клиента правильно? Я в замешательстве, потому что возврат клиента напрямую, похоже, упростит написание кода для модели, и его не намного сложнее настроить, если я использую ORM, такой как NHibernate. Тем не менее, я совершенно уверен, что это нарушило бы границы между совокупными корнями / репозиториями.

Во-вторых, где и как должно быть применено каскадное отношение при удалении для двух совокупных корней? Например, скажем, я хочу, чтобы все связанные заказы удалялись при удалении клиента. ICustomerRepository.Метод DeleteCustomer () не должен ссылаться на IOrderRepostiory, не так ли? Похоже, что это нарушило бы границы между агрегатами / репозиториями? Должен ли я вместо этого иметь службу CustomerManagment, которая обрабатывает удаление клиентов и связанных с ними заказов, которые ссылались бы как на IOrderRepository, так и на ICustomerRepository? В таком случае, как я могу быть уверен, что люди знают, что для удаления клиентов нужно использовать Сервис, а не репозиторий. Это просто сводится к обучению их тому, как правильно использовать модель?

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

Не совсем — хотя некоторые внесли бы это изменение по соображениям производительности.

Например, если я хочу получить подробную информацию о клиенте заказа, мне нужно будет взять CustomerID и передать его в ICustomerRepository, чтобы получить клиента, а не настраивать объект Order для прямого возврата клиента правильно?

Как правило, вы моделируете 1 сторону взаимосвязи (например, Customer.Orders или Order.Customer ) для обхода. Другой может быть извлечен из соответствующего репозитория (например, CustomerRepository.GetCustomerFor(Order) или OrderRepository.GetOrdersFor(Customer) ).

Не означает ли это, что OrderRepository должен был бы знать что-то о том, как создать клиента? Разве это не выходит за рамки того, за что должен отвечать OrderRepository…

OrderRepository Знал бы, как использовать ICustomerRepository.FindById(int) . Вы можете внедрить ICustomerRepository . Некоторым это может показаться неудобным, и они решат перенести это на уровень сервиса — но я думаю, что это излишне. Нет особой причины, по которой репозитории не могут знать друг о друге и использовать его.

Я в замешательстве, потому что возврат клиента напрямую, похоже, упростит написание кода для модели, и его не намного сложнее настроить, если я использую ORM, такой как NHibernate. Тем не менее, я совершенно уверен, что это нарушило бы границы между совокупными корнями / репозиториями.

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

Например, Customer не может содержать ссылку на OrderLines — поскольку OrderLines должным образом принадлежит как объект Order корню aggregate.

Во-вторых, где и как должно быть применено каскадное отношение при удалении для двух совокупных корней?

Если (и я подчеркиваю, если, потому что это специфическое требование) это действительно вариант использования, это указывает на то, что Customer должен быть ваш единственный совокупный корень. Однако в большинстве реальных систем мы фактически не стали бы удалять объекты, Customer с которыми связаны Order -мы можем деактивировать их, переместить их Order в объединенные Customer и т.д. — Но не удалять Order их полностью.

При этом, хотя я не думаю, что это чистый DDD, большинство людей допустят некоторую снисходительность при следовании шаблону единицы работы, в котором вы удаляете Order s, а затем Customer (что привело бы к сбою, если бы Order s все еще существовали). Вы могли бы даже поручить CustomerRepository выполнить эту работу, если хотите (хотя я бы предпочел сделать это более явным сам). Также допустимо разрешить очистку потерянных Order файлов позже (или нет). Здесь все зависит от варианта использования.

Должен ли я вместо этого иметь службу CustomerManagment, которая обрабатывает удаление клиентов и связанных с ними заказов, которые ссылались бы как на IOrderRepository, так и на ICustomerRepository? В таком случае, как я могу быть уверен, что люди знают, что для удаления клиентов нужно использовать Сервис, а не репозиторий. Это просто сводится к обучению их тому, как правильно использовать модель?

Я, вероятно, не стал бы использовать сервис для чего-то, что так тесно связано с репозиторием. Что касается того, как убедиться, что служба используется…вы просто не ставите public Delete на CustomerRepository . Или вы выдаете ошибку, если удаление Customer приведет к потере Order осиротевших ов.

Другим вариантом было бы иметь ValueObject, описывающий связь между заказом и ссылками клиента, VO, который будет содержать CustomerID и дополнительную информацию, которая вам может понадобиться — имя, адрес и т.д. (Что-то вроде ClientInfo или customerData).

Это имеет несколько преимуществ:

1. Ваши AR отделены — и теперь могут быть разделены, сохранены в виде потоков событий и т.д.
2. В ARS заказа вам обычно необходимо сохранить информацию, которая у вас была о клиенте на момент создания заказа, и не отражать в ней любые будущие изменения, внесенные в клиента.
3. Почти во всех случаях информации в объекте value будет достаточно для выполнения операций чтения (отображения информации о клиенте вместе с заказом).

Для обработки удаления / деактивации клиента у вас есть свобода выбора любого поведения, которое вам нравится. Вы можете использовать DomainEvents и опубликовать событие CustomerDeleted, для которого у вас может быть обработчик, который перемещает заказы в архив, или удаляет их, или что вам нужно. Вы также можете выполнить более одной операции над этим событием.

Если по какой-либо причине DomainEvents не являются вашим выбором, вы можете реализовать операцию удаления как операцию службы, а не как операцию хранилища, и использовать UOW для выполнения операций над обоими AR.

Я видел много подобных проблем при попытке выполнить DDD, и я думаю, что источник проблем заключается в том, что разработчики / моделисты склонны мыслить в терминах DB. У вас (у нас 🙂 ) есть естественная тенденция устранять избыточность и нормализовать модель предметной области. Как только вы преодолеете это и позволите своей модели развиваться и вовлекать экспертов домена в ее эволюцию, вы увидите, что это не так сложно и вполне естественно.

ОБНОВЛЕНИЕ: и аналогичный VO — OrderInfo может быть размещен внутри клиентского AR, если это необходимо, с только необходимой информацией — итогом заказа, количеством элементов заказа и т.д.