CODEWITHSUNDEEP
domain-driven-design
memumani
memumani

Reputation: 1

When we design an application which follows DDD , Which part of the application is responsible for making webservice calls?

Here is my scenario,

We are developing an ordering application for which the propducts should come from another system which has the product catalogue and rules for product offerability. We communicate with them through webservice.

Forming the service request to get the products involve more business logic for which i have to refer other entities like Address, customer profile , Marketing Strategy Rules , etc.

If i think of making the call inside product repository to populate the product entities , is it appropriate to refer the other entities and have such complex logic inside product repository ?

Some of them suggest to use Application Service , but i am not clear as from my understanding application service talks with domain and infrastructure to complete a specific task. And it will not hold any business logic.

What is the appropriate place and best way to do this ?

Upvotes: 0

Views: 83

Answers (3)

gt.guybrush
gt.guybrush

Reputation: 1388

A good discussion on architecture:

Domain driven design repository implementation in infrastructure layer

Application layer is good, but their interface must be in the core project

Upvotes: 0

Yugang Zhou
Yugang Zhou

Reputation: 7283

I recommend using a domain service and implement it with adapter calling webservice.

Repository strategy means you need to have product as an aggregate in your ordering bounded context. But product category and pricing is not the core domain in ordering bounded context. therefore you may not need product as an aggregate. I think you just need some simple value object in order aggregate to record what product is booked. hide other product' stuff behind a domain service.

An good example is cargo RoutingService mentioned in eric evans' DDD book.

Upvotes: 1

Lodewijk Bogaards
Lodewijk Bogaards

Reputation: 19987

According to DDD repositories should not contain any business logic. They should be simple tools for your domain layer to access and manipulate persisted data. All business logic should be held by domain services, aggregates, entities or value objects.

With all due respect, since this is very clearly written in all DDD manuals I suggest you (re)read them.

Good luck!

Upvotes: 0

Related Questions