DDD агрегатные корни

Question

У меня есть вопрос, касающийся DDD и ограниченного контекста.

Предположим, что есть два ограниченных контекста. В первом случае совокупный корень - это Клиент, который может опубликовать рекламу на веб-странице. Я полагаю, что в его поведение попадает, в свою очередь, у него есть метод PublishAdvertise (). Но второй ограниченный контекст имеет рекламу как совокупность. Это подразумевает, что Реклама имеет собственность Клиента, в силу ее принадлежности к Клиенту.

И Клиент, и Реклама уникальны в системе и базе данных.

Мой вопрос: целесообразно ли делегировать создание рекламы от клиента фабрике или внедрению зависимости?

Редактировать:

Я благодарю вас за ваши ответы и прошу прощения за отсутствие информации.

Внедрение зависимости:

Мне было интересно, как лучше всего разрешить данную ситуацию. У компании есть шаблоны Stock of Advert, если шаблон есть в наличии, его можно использовать, если нет, то он сдается в аренду кому-то. У компании есть план по увеличению запасов. Если клиент хочет сделать рекламу в этих шаблонах, он выбирает шаблон, и если его в наличии, все хорошо. Читая это, я предположил, что должен существовать сервис (домен) CheckAvailability(шаблон), поскольку из-за характера сервиса он не помещается в конкретный агрегат, поскольку он использует несколько агрегатов с проверками и запрашивает базу данных. В будущем, когда было бы больше Акций (некоторые арендованы у других компаний, возможно, у кого-то еще), я планировал использовать внедрение зависимостей для добавления этих Акций в сервис без изменения реализации. Вопрос в том, кажется ли это хорошей идеей?

Ограниченные контексты:

Что касается ограниченного контекста и базы данных. Да, есть один объект базы данных и два контекста, которые используют один и тот же объект базы данных. Заказ имеет ссылку на клиента, из-за принадлежности к клиенту выглядит примерно так

Заказ () Заказчик клиента (получить; частный набор;)

/// другие свойства и методы

Я был бы признателен за любую дополнительную информацию через ссылку, видео, книгу с точки зрения последствий наличия двух контекстов, подобных этим (Customer->Order___1:M), относящихся к одной и той же базе данных. Спасибо.

Answer 1

И Клиент, и Реклама уникальны в системе и базе данных.

Если это так, то проблема состоит в том, чтобы иметь эти понятия в двух ограниченных контекстах, которые используют одни и те же объекты БД! Разделение между двумя ограниченными контекстами является сильным, поэтому они не должны связываться, изменяя один и тот же объект БД.

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

А теперь ответим на ваш главный вопрос:

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

Answer 2

Абсолютно.

Одно дело связывать доменные объекты, а другое - работать с ними. У объявления есть некоторый связанный клиент, и клиент и объявление должны быть созданы в соответствующих доменных слоях (т. Е. Хранилище и сервис как минимум...).

Это правильно разделяет проблемы, так как вы не хотите, чтобы клиенты создавались там, где также создаются объявления, и наоборот.

Я думаю, вы уже знаете принцип единой ответственности.

Answer 3

Какие инварианты, связанные с клиентом, применяются Customer.PublishAdvertisement()?

• Если их нет, вам лучше перенести этот метод наAdvertisement совокупный корень в другом BC, возможно, делая его конструктором или AdvertisementFactory если логика построения сложна. Тот факт, что пользователь физического мира, который создает рекламу, является клиентом, не означает автоматически, что его общий корень должен иметь такой метод. Процесс создания рекламы может оставаться в Advertising BC с сервисом приложения Advertising в качестве точки входа.

• Если есть, то Клиент может испуститьAdvertisementPublished событие, на которое подписывается Реклама BC. Тем не менее, вы должны знать, что если вы следуете передовой практике "совокупность как граница согласованности", Заказчик не может быть немедленно согласен с объявлением, что означает, что может быть задержка и могут быть внесены несоответствия между тем, когда событие отправляется, и когда Advertisement сохраняется и, следовательно, видна другим клиентам.

  Обычно это не проблема, когда вы создаете новую AR, но имейте в виду, что состояние Customer который проверил инварианты и решил создать Advertisement может измениться и инварианты будут нарушены за это время до Advertisement сохраняется

  Очевидно, что, учитывая, что 2 BC совместно используют общую базу данных (что, как указывало @theDmi, вероятно, не очень хорошая идея), вы можете решить нарушить это правило и сделать вашу транзакцию охватывающей 2 агрегата. Не обязательно так плохо, если вы просто сохраняете новую рекламу и не изменяете ту, к которой потенциально можно получить доступ одновременно.

Что касается внедрения зависимости, я не вижу здесь связи - какая зависимость должна быть внедрена?