Say I have a class of User and that user has an Id & Name, in request response modeling, I would make a request with Name on it and a response with Id and Name, thereby my domain model would be

public User
    public int Id { get; set; }
    public string Name {get; set; }

In SOA (web api) this is ever so slightly wasteful as you're making a request with an always NULL id. Now let's scale to something complex that I won't go into detail on and say User now has 20 properties, 5 of them complex objects, so your http request is going to increase. To make it more fun let's say some of those properties cannot be exposed to the UI (ex. hash & salt).

What is the recommended approach for handling this common scenario in SOA architecture using domain driven design?

Edit: My question deals more with request/response than converting domain to dto, I think the takeaway is request = dto & response = dto.


Domain Driven Design does not provide an answer for this. DDD is more focused on business logic. Your problem is how to represent data as a string of characters sent to and from a client across a network.

What you need is a Data Transfer Object (DTO). Any time you need to transfer data between processes, where the call to another process is the expensive part of the operation (as it usually is with HTTP requests) then you need a class or group of classes that specialize in the data that gets transmitted — not behavior — data, and data only. DTO's tend to have public getters and setters. They can be composed of other DTOs, but they should not contain any methods.

The structure of these DTO's can be used to serialize them into a string for transmission across a network, as in Service Oriented Architecture. While Martin Fowler recommends coupling the serialization and deserialization of DTOs together in the same object (which means adding methods to a DTO) this can also be accomplished with 3rd party libraries. Every tech stack has libraries for converting to and from JSON and XML, which are pretty standard data formats. These libraries often utilize class reflection to infer the data structure from the object members and type information.

  • Would I have a dto for the request and a dto for the response then? – RandomUs1r Aug 30 '18 at 16:15
  • @RandomUs1r: Yes. Depending on the use case they might be the same DTO or different classes. Depends on your needs. – Greg Burghardt Aug 30 '18 at 16:36
  • Gotcha, so going back to my example in the question, say I have UserRequest & UserResponse where UserRequest has an Id and UserResponse has a name, what would the dtos be named? – RandomUs1r Aug 30 '18 at 16:54
  • @RandomUs1r: Wouldn't "UserRequest" and "UserResponse" be the names of the DTOs? That's what I would expect. The presence of the word "request" or "response" does not seem like a Domain Concept to me. If they are actually concepts, I've seen people suffix the DTO classes with "Dto" - FooDto – Greg Burghardt Aug 30 '18 at 16:56
  • I suppose, I've seen the dto suffix too, but in the infrastructure layer sometimes mapped over to POCO using something like automapper. It sounds like the RR pattern is still kicking in the SOA world is my conclusion from all this. – RandomUs1r Aug 30 '18 at 17:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.