Should API infrastructure classes be part of the domain in DDD?

Question

I work on a backend application exposing a REST API and I (try to) use Domain Driven Design in my project.

The REST API operates on a fixed set of domain classes. For every agregate root from the domain there is a separate REST endpoint. However, despite all the efforts, there are cases when new classes, not deriving from the domain classes (infrastructure classes) emerge, e.g.:

• a class holding statuses of batch operations [{"id": 1, "status": "success"},{"id": 2, "status": "failure", "message": "detailed message"}]
• a class with the columns chosen by the user [{"column": "id", "order": 1}, {"column":"created", "order": 2 }]

Now two options:

• is it ok to have the REST API expose classes that are not part of the domain?
• or should these classes become part of the domain?

Answer 1

You shouldn't try to build the REST API directly against your domain model. There are quite a number of responsibilities that you need for such an interface that would mess up your domain model. E.g. transaction control, security, input validation are things that you probably need, but that don't belong in the domain model.

This is what application services are there for.

Build a thin layer around your domain model that contains the application services (often called Service Layer). The app services are the direct clients of the domain model. They are usually organized around Use Cases rather than aggregates. Now your REST API is the direct client of the app services instead of the domain model.

The two classes that you mention would then also fit into the service layer nicely.

Edit:

Note that when using Hexagonal Architecture (which is a good fit for DDD), the service layer is not the same as the persistence layer. The service layer uses the persistence layer to load and save aggregates to the DB.