DDD имеет дело с двумя доменами, выполняющими одинаковые действия.

Вам нужны два домена для связи друг с другом. Вы можете общаться, используя различные методы, но одним из распространенных способов является использование REST API. В вашем домене Магазина вам нужно что-то, что общается или знает, как общаться с API. Обычно я реализовывал их как службу, которая оборачивает вызовы API. Сервис сможет понимать ваш домен Ubiquitous language и переводит его в команды API. Вы можете использовать события домена, чтобы, возможно, прослушивать, когда продукт был создан, а затем вы можете связать магазин с продуктом или реализовать какой-либо механизм опроса.

Был запрошен пример, так что вот:

Вызов из пользовательского интерфейса (вероятно, из контроллера)

StoreService.CreateStore(storeName: String, newProduct : StoreProduct) Вы можете передать примитивы для представления нового продукта. Это позволяет создавать новый продукт без необходимости создания для него нового класса. Впоследствии вам не понадобится класс общей инфраструктуры или преобразователь между вашим доменом и слоями пользовательского интерфейса.

StoreService

public StoreService
{
      public StoreService(ProductApiClient productApiClient...)...
      public void CreateStore(string StoreName, StoreProduct prod...)
      {
             var newStore = StoreFactory.Create(storeName);
             //below might be better as an asynch call but for simplicity
             //keeping it all synchronous
             var newProd = productApiClient.CreateProduct(prod);
             //check if product was created successfully, if so
             newStore.Add(newProd);
             //save
             StoreRepo.Create(newStore);
             //check if store was created successfully
       }

Основные моменты, которые нужно взять отсюда:

1. Создайте свою совокупную сущность с помощью фабрики (в этом состоянии она не сохраняется).
2. Вам нужно репо для сериализации и сохранения вашего нового хранилища в вашем хранилище данных.
3. productApiClient будет переводить между вашей моделью домена и запросом к productApi. Он знает, как генерировать запрос API (например, REST) ​​для заданных объектов домена.
4. ProductApiClient вернет объект домена из ответа API.
5. Вы добавляете новый продукт в магазин, используя сущность магазина.
6. Вы сохраняете свой магазин, используя репо
7. Вы можете выбрать более асинхронный подход, если вызов API занимает много времени.

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

Эта бизнес-проблема очень распространена. Вы наверняка можете найти несколько примеров систем электронной коммерции с DDD.

Типичная ситуация: вы не закончили разработку UL. Если вы обсуждаете Магазин (я не буду отмечать его как код, поскольку я говорю о терминах UL, а не о классах) со специалистами в своей области, вы можете обнаружить, что Магазин заботится только о Доступности Продукта, а не о самом Продукте.

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

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

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

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