Costs&Benefits of doing DDD with/for REST api that doesn't use verbs but nouns only?

Question

So, DDD is all about the behavior, ergo, methods. If we use our domain through the REST api that doesn't have verbs but nouns only (which REST purists advocate), then we have a huge problem calling our ddd methods. Either we need to establish some custom protocol where http patch requests would contain method name & params for the given noun and/or we need to have some anti-corruption layer to map those to ddd methods.

On the other hand, introducing verbs to REST api solves this in an elegant way (twitter api, e.g.) but then again it has its own nuances.

Is there some standard way how is this being solved when using ddd+rest?

Answer 1

Is there some standard way how is this being solved when using ddd+rest?

TL;DR: Forms.

---

You should start from Jim Webber's 2011 talk: Domain Driven Design for RESTful Systems.

HTTP is the application protocol of transferring documents. You have to learn how to narrow HTTP into a domain application protocol. That is: you have to learn how to use HTTP to trigger business activity as a side effect of moving documents around the network.

REST isn't about "nouns", it's about documents ("resource" being a generalization of "document"). If I want information from you, I ask for a copy of your document. If I want to send information to you, I propose an edit to your document.

So if I want to tell you that your cargo shipping container has arrived in Stockholm, I ask you (GET) for a document that includes the last known location of your container, then I use my local editor to change the location field to SESTO, and then I send a copy of that document back to you (PUT) proposing that you change your document to match my copy.

If the document is really big, and the changes are small, then I might send you a document that describes my changes (PATCH) rather than sending you the entire document (PUT).

Often, we don't want the client to be editing the document, but rather instead to tell us what's going on, so that we can edit the document. So we instead use web forms; you copy your new information into the form that I provide, and submitting that form proposes an edit (not to the document that has the form, but instead to the edit that the form is pointing to).

In effect, we're using the web form to communicate information by creating an HTTP request with a command message (yet another kind of document) in the payload.

So what we've got is a general purpose document transfer application that understands a number of different idioms. We get to choose the most suitable document model for our domain, keeping in mind that "narrowing" the protocol includes making some trade offs (which information should be communicated by saving a new document versus modifying an existing document, which documents should be accessible anonymously, which previously cached documents should be invalidated by new information, and so on).

---

what if you have 3 domain methods that change state of location attribute?

A few possibilities here.

One is that your domain model is wrong. For the specific example of a container in a port, you can't magically teleport the container across the world by editing the field. So your domain model doesn't really have "veto" authority over the location information being sent to it.

Another possibility is that of your domain methods, only one is appropriate for the case of an edit made to the resource in your REST api. That can happen, but it is unusual.

Third possibility is that your API is responsible for comparing the two document representations and computing the appropriate model to invoke in the domain model. Yuck.

Which is why you are more likely to see documents that describe tasks rather than direct edits of representations (see previous paragraph about trade offs).

It's still your job to take the document that describes a task and figure out which command/commands need to be invoked on which domain entities in what order with which arguments.