Can we use REST + Event Sourcing + CQRS together

Question

I understand the basics of REST + Event Sourcing. I never worked on a strict RESTful API and not either in any Event Sourcing project.

Can someone explain if both can be used together?

As in event sourcing, the client send events, does this mean that on the server there is a single collection of event and all POSTs of the API will be on that collection, to add events to it?

How can the client discover the commands it can send to the server?

Answer 1

Short answer - yes we can.

All things which you are enumerating, I mean REST, event sourcing (ES) and CQRS are for different purposes. So I dont see any problem to grab it all together.

Lets look - REST is a way to do a web-service API, ES is a tool to communicate inside a domain and CQRS as a mid level architecture.

Well, in ES the client (if we talking about a web-client) does not send domain events. If you mean another bounded context and that bounded context is a part of the your domain, I guess an event transporting should be solved by another way, a service bus or something like this would be great. If a bounded context is not a part of the your domain you should communicate it through ACL and API not a raw domain events. :)

Short about commands. Again, in the CQRS a commands lives inside an application boundary. External clients ( web-clients, api-clients ) shouldn't have ability to send application commands directly. You should provide an API ( internal client ) which would allow to do some service's use-cases but not a single and separate commands. For a self made example you can try get answer on a very popular SO's question - how to check username uniques when we use CQRS? :)

Answer 2

REST is a delivery method, it determines the interface of your application. You use REST mostly with immediate consistency model, but it can support an eventual consistency model by responding 202 accepted by commands.

Event sourcing is a general data storage mechanism. You use event sourcing usually with an eventual consistency model along with domain driven design, and command and query segregation, but it can support an immediate consistency model probably by a multi-phase commit.

They solve completely different things in your application and they are compatible with each other, so you can use them together.

As in event sourcing, the client send events, does this mean that on the server there is a single collection of event and all POSTs of the API will be on that collection, to add events to it?

You completely misunderstood the concept. You can store an event sequence in an event storage. Event are state changes, so if you store every state change of your application and replay it in the proper order, then you can recreate the current state of your application. This is very good, because you can migrate data to another database simply by replaying the events and transforming them into database queries. You can do just the same to create a query cache using a regular database. So your clients can read that query cache instead of always recreating the current state from the grounds.

The events are usually not created by the client. By domain driven design, your domain logic creates domain events by processing commands.

How can the client discover the commands it can send to the server?

By REST the clients use links to send requests to the REST service. The REST service can process those requests and transform them into commands and queries. The commands are processed by the domain logic, and will result in raising domain events. The queries are transformed into database queries which address the query caches.

Answer 3

Can someone explain if both can be used together?

Yes. The client (browser) simply does what it wants to do and the (http) server can record those actions as events.

As in event sourcing, the client send events, does this mean that on the server there is a single collection of event and all POSTs of the API will be on that collection, to add events to it?

No. The client can be the originator of events, but should not known what constitutes an event in order to prevent tight coupling between the server and the client based on that collection of events. Event Sourcing should be encapsulated and is hidden from the actor.

How can the client discover the commands it can send to the server?

This is not necessary if you don't need to send events on the same collection as you've suggested in your previous question. You can simply publish a REST API in any way you want and hide the event sourcing from the client/actor. Have a look at http://restdesc.org/.