CODEWITHSUNDEEP
domain-driven-design
Rushil Ahuja
Rushil Ahuja

Reputation: 17

Preparing complex request payload for external service in DDD

I am very new to domain driven design and having a hard time understanding one thing which I will ask towards the end of this post.

Following are the facts that I am aware of, about DDD.

  1. External REST call to get data for performing domain/business logic should happen in application layer.
  2. Factories are a part of domain layer and should be used for creating domain objects.

Now, I am trying to devise a REST micro service. The payload of the POST service that I am designing, let's call it SearchRequest, is something that I am considering a part of my domain. SearchResponse, which is the response of my micro service's REST api is again a part of the domain.

My first question is, should SearchRequest & SearchResponse be a part of my domain model?

Also, for preparing SearchResponse I need to make an external API call, the request payload to which is present in a third-party jar. I need to write a complex logic to prepare the request payload for external api using data from SearchRequest.

Should the request payload for external API be a part of the domain? If yes, then I can have a factory in the domain layer to prepare the request payload. If not, then in which layer should I have the logic to create the same. Can I use factory in the application layer for creating objects that are not a part of the domain.

Upvotes: 1

Views: 1159

Answers (2)

inf3rno
inf3rno

Reputation: 26139

The main rule here, that the domain model must not depend on anything. If it depends on something, then you must decouple it with interfaces or events.

I think the answer depends on how much these external API calls creep into your domain model.

  • a.) If it is just one call, then you can define an infrastructure service interface for the external API call and inject the infrastructure service into a domain service and call that domain service from your domain.
  • b.) If you use several different calls, then you can have multiple domain services and multiple infrastructure services.
  • c.) If you go real complex, then you can define repositories, entities, etc. too, maybe even a separate bounded context and end up with a complete anti corruption layer.

Upvotes: 0

Farhan Nasim
Farhan Nasim

Reputation: 817

My first question is, should SearchRequest & SearchResponse be a part of my domain model?

Ideally, no. Request and response are application layer constructs. Application layer is meant to serve various use cases of a domain; it is not the domain itself.

Should the request payload for external API be a part of the domain? If yes, then I can have a factory in the domain layer to prepare the request payload.

Firstly, the external API payload is not part of your domain; it belongs to a different bounded context, expressed in its own ubiquitous language. A little background before coming to the exact potential solution: Two bounded contexts must not mingle freely for the obvious reason that the same concept may have different meanings in different bounded contexts. Communication between two domains must happen through an anti-corruption layer (ACL) that maps the external bounded contexts into your own and vice versa.

As Vaughn Vernon suggests in his book, the ACL may be implemented either as a domain service or even a repository, both belonging to the domain layer. Assuming you go with the domain service, pass the necessary fields from SearchRequest to a domain service method that makes the external call. The method hides the external service request construction logic and also the external service response mapping to your domain objects. The domain service contains references to objects (in your case the types defined in your third-party JAR) necessary to construct the external request but its clients remain ignorant about the external service's domain (bounded context).

Upvotes: 1

Related Questions