3

According to Richardson Maturity Model there are several levels of maturity in REST approach. http://martinfowler.com/articles/richardsonMaturityModel.html

Since DDD uses ubiquitous language, I am wondering what level of maturity is recommended, if a REST API is a presentation layer of my DDD project?

Using ubiquitous language could let to some interesting names inside a bounded context, but when exposing it to outside world, how could this be translated into an appropriate level of maturity?

4

REST maturity levels and DDD are orthogonal concerns.

Your Ubiquitous Language doesn't care whether it's reflected deep down in the payload of a SOAP message, in a resource URI, or in a domain-specific content type, as long as it remains pervasive and coherent throughout its Bounded Context.

If your Bounded Context includes both the client and server parts, HTTP will inevitably stand in your way, breaking the semantic continuity between the client and Application Service. If you adhere to the First Law of Distributed Objects, there's no way around it. When reading or programming client code, it will never be as fluid and easily discoverable as calling a method named after a domain concept on an object named after a domain concept. There will always be an impedence mismatch between the HTTP protocol commands and your domain verbs or commands.

If the BC ends at the Application Layer and/or acts as a Supplier or an Open Host Service to other systems, HATEOAS might provide a more clearly expressed and discoverable Published Language (in the form of a Domain Application Protocol) than the other levels, with less effort. But well-documented level 0, 1 or 2 implementations can remain perfectly valid depending on other contextual criteria.

  • So you are suggesting that REST endpoints use path and name according to chosen level of maturity and completely disconnect it from ubiquitous language used in application layer? – Dario Granich May 4 '16 at 12:36
  • No, the ubiquitous language has to be pervasive wherever it applies. If we're talking about level 0, you're not going to use http://yourdomain/system12/service8839 where you could use http://yourdomain/<BoundedContextName>/<ApplicationServiceName> for instance. – guillaume31 May 4 '16 at 12:52
  • What about we're talking about level 1, and it is resource based IE. Rather different then ubiquitous lang? – John May 4 '16 at 16:21
  • @John in level 1, ubiquitous language terms are both in the URI and in the requests themselves. Everything is POST, so you have to formulate your intent in the payload somehow. – guillaume31 May 5 '16 at 8:01
  • Here again, you're not going to send { "action": "erase" } to /users/123 if the real domain terms are "Disable" and "Account". That would defeat the purpose of having a Ubiquitous Language. However, I don't think lower levels of REST "purity" (or non-REST approaches, for that matter) mean straying away from DDD. – guillaume31 May 5 '16 at 8:11
0

If we consider that you're doing the server side and your "client" the client-side. A DDD would be something at least of HATEOAS approach but even probably more :

  • adding new HTTP method relevant to the domain. Example DELETE could fit for a disabling and a reenabling could have a verb RESTAURE. (Yes this can be done with PUT but this is less domain driven).
  • fully human readable URL which could conflict with the ubiquitous language defined with the client. For instance in the level 1 the URI people/1/address will give the address of the people with id one. But the ubiquitous language could expect to have something like people/address/id=1.
  • Use another format that the one given in the link. Something that would follow the ubiquitous language instead of XML.

But if you're doing the client-side, your "REST" service can be at the level 0 (though it would not be a REST service according to the link) since it will be hidden from the client.

This is only a rough thought of the possibilities.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.