Search code examples
restservicedomain-driven-designcqrs

CQRS Read Models & REST API

We are implementing a REST API over our CQRS services. We of course don't want to expose any of our domain to users of the REST APIs.

However, a key tenant of CQRS is that the read models generally correspond to a specific view or screen.

  1. With that being the case, it seems logical that the resources in our REST API, will map virtually 1:1 with the read / view models from our queries (where the queries return a DTO containing all the data for the view). Technically this is exposing a part of our domain (the read models - although returned as DTOs). In this case, this seems to be what we want. Any potential downsides to being so closely coupled?

  2. In terms of commands, I have been considering an approach like: https://www.slideshare.net/fatmuemoo/cqrs-api-v2. There is a slide that indicates that commands are not first class citizens. (See slide 26). By extension, am I correct in assuming that the DTOs returned from my queries will always be the first class citizens, which will then expose the commands that can be executed for that screen?

Thanks

Solution

  • Any potential downsides to being so closely coupled?

    You need to be a little bit careful in terms of understanding the direction of your dependencies.

    Specifically, if you are trying to integrate with clients that you don't control, then you are going to want to agree upon a contract -- message semantics and schema -- that you cannot change unilaterally.

    Which means that the representations are relatively fixed, but you have a lot of freedom about about how you implement the production of that representation. You make a promise to the client that they can get a representation of report 12345, and it will have some convenient layout of the information. But whether that representation is something you produce on demand, or something that you cache, and how you build it is entirely up to you.

    At this level, you aren't really coupling your clients to your domain model; you are coupling them to your views/reports, which is to say to your data model. And, in the CQRS world, that coupling is to the read model, not the write model.

    In terms of commands, I have been considering an approach like...

    I'm going gently suggest that the author, in 2015, didn't have a particularly good understanding of REST by today's standards.

    The basic problem here is that the author doesn't recognize that caching is a REST constraint; and the design of our HTTP protocols needs to consider how general purpose components understand cache invalidation.

    Normally, for a command (meaning here "a message intended to change the representation of the resource"), you normally want the target-uri of the HTTP request to match the identifier of the primary resource that changes.

    POST /foo/123/command

    Isn't particularly useful, from the perspective of cache invalidation, if nobody ever sends a GET /foo/123/command request.