Domain Driven Design Calling Remote APIs

user_7844012 0
Viewed 85

I am new to DDD and this is the first project for me to apply DDD and clean architecture,

I have implemented some code in the domain layer and in the application layer but currently, I have a confusion

now I have an API which is placeOrder

and to place the order I need to grab data from other microservices, so I need to grab production details from product service and address details from user profile microservice

my question is, should these data are pulled into the domain layer or in the application layer?

is it possible to implement a domain service that has some interfaces that represent the product service API and use that interface in the domain layer and it will be injected later using dependency injection or should I implement the calling of this remote API in the application layer?

please note that, calling product service and address service are prior steps to create the order

ddd-service dddd domain-driven-design
1 Answers

Design is what we do when we want to get more of what we want than we would get by just doing it. -- Ruth Malan

should these data are pulled into the domain layer or in the application layer?

Eric Evans, introducing chapter four of the original DDD book, wrote

We need to decouple the domain objects from other functions of the system, so we can avoid confusing the domain concepts with other concepts related only to software technology or losing sight of the domain altogether in the mass of the system.

The domain model doesn't particularly care whether the information it is processing comes from a remote microservice or a cache. It certainly isn't interested in things like network failures and re-try strategies.

Thus, in an idealized system, the domain model would only be concerned with the manipulation of business information, and all of the "plumbing" would be somewhere else.

Sometimes, we run into business processes where (a) some information is relatively "expensive" to acquire and (b) you don't know whether or not you need that information until you start processing the work.

In that situation, you need to start making some choices: does the domain code return a signal to the application code to announce that it needs more information, or do we instead pass to the domain code the capability to get the information for itself?

Offering the retrieve capability to the domain code, behind the facade of a "domain service" is a common implementation of the latter approach. It works fine when your failure modes are trivial (queries never fail; or abort-on-failure is an acceptable policy).

You are certainly going to be passing an implementation of that domain service to the domain model; whether you pass it as a method argument or as a constructor argument really depends on the overall design. I wouldn't normally expect to see a domain entity with a domain service property, but a "use case" that manipulates entities might have one.

That all said, do keep in mind that nobody is handing out prizes for separating domain and application code in your designs. "Doing it according to the book" is only a win if that helps us to be more cost effective in delivering solutions with business value.

user_547340
Related