Application services use both DTOs and domain objects

[marcusolsson]

In the original Java version, the application services are divided into a service using domain objects and a facade that accepts DTOs, converts them to domain objects and dispatches them.

Should request/response structs contain DTOs or domain objects?. If request contains DTOs, where should translation occur?

I'm reluctant to place translation in application service since it should focus on fulfilling the use case.

Alternatives?

[marcusolsson]

For now, the pragmatic fix is to add JSON tags to the Itinerary domain object. This means the introduction of non-domain concepts in one of the domain packages. This may change but for now it's the simplest solution.

[dkushner]

@marcusolsson, hey I just had a quick question surrounding what was done for this fix. Was the change simply the inclusion of the encode/decode functions in the transport package of the relevant domain package?

[marcusolsson]

For example, booking defines its own Location and Cargo that corresponds two what is returned from the API. The danger of returning a raw domain object in the REST API is that you're likely to introduce fields and methods related to how the JSON response should look like. This is something that has nothing to do with the domain and ideally the concerns should be separated.

This usually manifests in two objects, one domain object and a representation of the domain object meant for transport. In the case of Itinerary though, the two objects are exactly the same and it felt non-pragmatic to introduce an identical object. Instead JSON tags were added to the domain object, which introduces transport logic in the domain model. It's a trade-off.