DDD: проблема с доменными службами, которым необходимо получать данные как часть их бизнес-правил.

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

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

Я бы отнесся к этой проблеме прагматично и немного изменил вашу реализацию, чтобы она была простой:

// Somewhere in the application layer:
public void ApplyProductFamilyDiscount()
{
  // make sure everything is in one transaction
  using (var uow = this.unitOfWorkProvider.Provide())
  {

    var familyProducts = this.productService.ApplyFamilyDiscount();

    // persisting
    foreach (var familyProduct in familyProducts)
    {
      this.productRepository.Save(familyProduct);
    }

    uow.Complete();
  }
}

Реализация в сервисе предметной области:

// some method of the product domain service
public IEnumerable<Product> ApplyFamilyDiscount()
{
    var spec = new FamilyProductsSpecification();
    var familyProducts = this.productRepository.findBySpecification(spec);

    this.familyPriceReductionPolicy.Apply(familyProducts);

    return familyProducts;
}

При этом вся бизнес-логика прохождения всех продуктов семейства старше одного года с последующим применением текущей скидки (50 процентов) инкапсулируется внутри службы домена. Прикладной уровень снова отвечает только за то, чтобы правильная логика вызывалась в правильном порядке. Именование и то, насколько универсальными вы хотите сделать методы службы домена, предоставляя параметры, конечно, могут нуждаться в настройке, но я обычно стараюсь не делать ничего слишком общего, если в любом случае есть только одно конкретное бизнес-требование. Так что, если это текущая скидка на семейный продукт, я бы уже знал, где именно мне нужно изменить реализацию - только в методе службы домена.

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

Примечание. Поскольку я не знаю реализации FamilyPriceRedcutionPolicy, я могу только предположить, что она вызовет соответствующий метод для агрегатов продуктов, чтобы позволить им применить скидку на цену. Например. используя такой метод, как ApplyFamilyDiscount () для агрегата Product. Имея это в виду, учитывая, что цикл по всем продуктам и вызов метода скидки будет только логикой за пределами агрегата, имея этапы получения всех продуктов из репозитория, вызывая метод ApplyFamilyDiscount () для все продукты и сохранение всех измененных продуктов могут действительно просто находиться на уровне приложения.

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