Когда мы разрабатываем приложение, которое следует за DDD, какая часть приложения отвечает за вызовы webservice?

Question

Вот мой сценарий,

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

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

Если я думаю о выполнении вызова внутри хранилища продуктов для заполнения объектов продукта, целесообразно ли передавать другие объекты и иметь такую ​​сложную логику внутри репозитория продукта?

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

Что такое подходящее место и лучший способ сделать это?

Answer 1

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

При всем уважении, так как это очень четко написано во всех руководствах DDD, я предлагаю вам прочитать их.

Удачи вам!

Answer 2

Я рекомендую использовать службу домена и реализовать ее с помощью адаптера, вызывающего webservice.

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

Хорошим примером является грузовой маршрут RoutingService, упомянутый в книге DDD Эрика Эванса.

Answer 3

Хорошее обсуждение архитектуры:

Domain driven design repository implementation in infrastructure layer

Прикладной хорошо, но их интерфейс должен быть в базовом проекте