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

Question

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

It’s clear that the REST API is the application contract, while the domain model is part of the implementation, and therefore it’s best to separate these two things, so changing the domain model does not automatically mean changing the REST API.

However, I think that in the case of small projects (where the REST API has only one consumer - the javascript interface developed by one team), the advantages of having separate models do not justify the cost of separating the models (different classes - domain model and resource representations and mapping code between models). Obviously, at the domain level, there can be no references to a specific REST infrastructure code (to separate the problems).

Should the domain and REST models be separated?

Answer 1

When using the DDD API, the REST must 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 client API. Otherwise, customers should be aware of the nuances and subtleties of your domain, which most likely makes it difficult to use the API.

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

However, I think that in the case of small projects (& hellip;), the benefits of having separate models do not justify the cost of separating the models (& hellip;).

I agree that there are projects in which the shared domain model and REST API are excessive. However, these cases are not candidates for DDD because you will not use DDD to justify its cost.

Answer 2

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

Because the Internet is a completely different world than your primary domain level. The methods in your entities are especially difficult to translate, since HTTP has only a few verbs. If you want to expose your application through REST, you must train your HTTP domain processes, and this usually means compromising and developing resources other than your domain objects.

Of course, you should find the terms from Ubiquitous Language in messages exchanged between the HTTP client and server, and in the domain application protocol, if you do HATEOAS, but the network will definitely distort your domain representations.

The point of REST is not to recreate a high-quality model of your domain and its processes, but to deliver them in an HTTP-compatible way, losing as little as possible during translation. However, it remains a translation.

Answer 3

I think one more thing to consider is who uses your REST API. If you are developing an interface for an application, you can say that everything is still happening within 1 limited context. Just the part lives in the client / javascript. In this case, I think it makes sense to expose your model in your vacation api.

in this case, the REST api may just be a means of communicating with your domain services, for example.

Answer 4

You can bind your business logic to REST resources based on your domain model. For example, whenever someone sets is_published = 1, you can notify the administrator, perform an additional check, etc. by connecting to an event or mutator. Sometimes things can be too complicated and strange to do this, so you can mark certain attributes as unmodifiable, and then create custom actions to modify them, which you reveal, if that makes sense. I think that if you design correctly, you don’t even need these "user actions". Facebook does not use any graphical APIs, I do not think so. I am thinking of developing a framework based only on demonstrating the level of the model; I still think this is a good idea.

Answer 5

I think that the main advantage of the REST API is the provision of a service (usually server-side, not SPA) to third-party REST clients. If you use HATEOAS and other self-describing message solutions such as RDF, REST clients will break much harder due to changes in the REST API. For small projects - "where the REST API has only one consumer - the javascript interface developed by one team" - I don’t think it’s worth having the right REST API. Most people use its simplified version, which I call the CRUD API, and they can be good for these projects.

There may be a 1: 1 mapping between CRUD resources and domain objects of the anemic domain model. If we are talking about real objects (rather than data structures) using not only CRUD methods, then you should translate between resource.verb and object.method, for example:

POST /dogs/{id}/barking -> domain.dog.bark() 

If we are talking about more complex things associated with several domain objects and a unit of work (transactions), then you need to add another layer for application services, otherwise you would transfer the entire complex operation, including transaction processing, to the client. In these cases, you translate between resource.verb and applicationService.operation, for example:

 POST /dogs/{id1,id2,..}/barking -> dogService.multiDogBark(...) -> UnitOfWork{domain.dogs[ids[i]].bark()} 

I think that most developers confuse this approach of CRUD services + an anemic domain system model with the REST services + domain model approach, therefore they ask this question and therefore there are many "REST" structures that add a 1: 1 domain object - a CRUD resource. mapping, or maybe even an ORM object — mapping of CRUD resources. I find this trend very destructive, and I think the main reason is that developers learn certain technologies only superficially from short articles or question and answer sites instead of reading books and dissertations, where they can gain deep knowledge on a relevant topic. I think this is a problem of the Y + generation, due to which we lose the ability to read long texts due to the use of digital technology. We are driven by instant rewards instead of deferred rewards that give a long text ...