DDD: How to reconcile a BoundedContext with REST/WebService DTO's?

Question

I'm just starting to learn about DDD, and I'm trying to understand how Bounded Contexts can be reconciled with client facing API's like REST/WebServices that use DTO's.

For example: your system exposes it's API to the public with a standard WebService, with CRUD style operations for DTO objects with many fields defined via a WSDL. You create a Bounded Context to handle your Domain's business logic, using a "non-anemic" domain model - so that your domain objects don't simply have a bunch of setters and getters - instead they have methods defined using vocabulary from your ubiqitious language. How would one reconcile the difference between their web service DTO and the Bounded Context? It seems to me this could add a huge amount of complexity, and I'm wondering if there are some well defined ways to solve this.

Answer 1

The domain model is exposing commands and queries that can be used by the application. So the application (more specifically, the "anti-corruption component") is responsible for taking the DTOs and re-expressing them in a form that the domain understands.

If you are building your application from the domain model out, this is really straight forward: your DTOs just become representations of the commands themselves, and the api becomes a series of endpoints that handle those commands on behalf of the remote client. And the ubiquitous language ripples OUT from the domain model all the way to the clients.

Trying to work inwards toward the domain model, from an api that exposes all changes as a CRUD operation... yeah, that's going to suck all the way. Essentially, you end up writing an anti corruption layer that reviews the proposed change, and tries to deduce from it the intent of the operation in the client. Bad news.

The good news: if you are following Greg Young's recommendations on when to use DDD (ie: in the parts of your business where you have a competitive advantage), then there's a huge amount of leverage -- the value of improving the process may be high enough to offset the cost of deprecating the CRUD api.

Horses for courses.