Adam Siemion Adam Siemion - 1 month ago 5
reST (reStructuredText) Question

Why the domain model should not be used as resources in REST API?

I came across a statement that the domain model designed in accordance with DDD should not be used as resources in a REST API (source).

It is clear that a REST API is a contract of the application while the domain model is part of the implementation and therefore it is the best to keep these two things separate, so that a change in the domain model does not automatically imply a change in the REST API.

However, I think in case of small projects (where the REST API has just one consumer - the javascript frontend, developed by one team) the benefits of having separate models does not justify the cost of separating the models (different classes - domain model and resource representations and mapping code between the models). Obviously the domain layer cannot have any references to REST specific infrastructure code (to keep separation of concerns).

Should the domain and the REST models be separated?

Answer

When using DDD, the REST API should always be separated from the domain model.

The main reason for this is simplification - you don't want to leak the complexity of the domain model through the API to the clients. Otherwise, clients need to know about the nuances and intricacies of your domain, which most probably makes the API hard to use.

And the main driver for using DDD is a complex problem domain, so this is always a problem.

However, I think in case of small projects (…) the benefits of having separate models does not justify the cost of separating the models (…).

I agree that there are projects where a separated domain model and REST API is over-engineering. However, these cases aren't candidates for DDD, because you will not benefit from DDD enough to justify its cost.