Geek Answers Handbook

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

I am working on a backend application representing the REST API, and I am (trying) to use the Driven Design project in my project.

The REST API works with a fixed set of domain classes. There is a separate REST endpoint for each agregate root in the domain. However, despite all efforts, there are cases when new classes appear that are not related to domain classes (infrastructure classes), for example:

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

Now there are two options:

  • Is it good for the REST API to expose classes that are not part of the domain?
  • or should these classes become part of the domain?
+5
source share
1 answer

You should not try to create a REST API directly against your domain model. There are a number of responsibilities for this interface that can ruin your domain model. For instance. transaction management, security, input verification - these are things that you probably need, but that do not belong to the domain model.

That's what application services are for.

Create a thin layer around your domain model that contains application services (often called service levels). Application services are direct clients of a domain model. They are usually organized around the use of cases, rather than aggregates. Your REST API is now a direct client of application services instead of a domain model.

The two classes you mentioned will also fit in well with the service level.

Edit:

Please note that when using the hexagonal architecture (which is suitable for DDD), the service level does not match the storage level. The service level uses the save level to load and save aggregates in the database.

+5
source

More articles:


All Articles