Exposes CQRS system functionality through a set of restful APIs

Command and query responsibility separation (CQRS) is a schema pattern that separates the system's read (query), write (command) operations into two separate subsystems. Commands are usually executed asynchronously and stored in a transactional database, while read operations are usually final and the data comes from a normalized view.

In this paper, we present a way to create a restful API for the CQRS system. This approach combines the semantics of HTTP, the resource-based style of the REST API, and the ability to handle certain issues of distributed computing, such as final consistency and concurrency.

We also provide a prototype API, built on the m-r CQRS prototype written by Greg Young, which is also known as simplestpossiblething. M-r can be considered the de facto standard for CQRS prototypes, and it inspires many teams to adopt and create CQRS systems. Although the M-r prototype is simple, it has been able to demonstrate some of the opportunities and challenges of using restful CQRS systems in the real world.

We review the M-R domain model in the next section, and then explore the API design for the relevant features. Finally, we will discuss some of the choices we have made and discuss some of the concepts and theoretical content of restful m-r.

M-r Field

The M-R model is a simplified domain model for inventory management systems where you can create new inventory items (assuming it is some type of product), rename or deactivate them (that is, tombstone ). Items that are deactivated will no longer be visible to the user, and all active items can be retrieved and can see all the details of each item. You will also be able to add or reduce these inventory items, specifying the added or reduced item data. In other words, after the inventory is set up, you can start using the system.

The user will view the list of items or the details of the item through a synchronized query, and the changes to the status of the item will be implemented by command. In the real world, commands should be executed asynchronously, but because the code uses an in-memory event bus and event-handler function, the commands are executed synchronously in the final implementation.

The M-R model implements the CQRS: commands and queries are stored separately in different places, and completely different parts of each free system are processed.

In addition to CQRS, M-r also uses the event traceability (incident Sourcing) as its persistence mechanism. In this way, modifications to the domain model are captured as a series of events that are stored in the order in which they are called. In order to get the current state of a model, all events need to be replayed in the order in which they occur. In other words, the state information of the entities in the model is not persisted. For example, if we create an inventory item and then rename it two times, we will get a inventoryitemcreated event and two inventoryitemrenamed events, These events will be stored in the event store.

Events are sequential, and each event comes with a version number that is checked at concurrency. For example, if an inventory item is renamed on a version 2 basis, but there is just another rename on the same item and the current version of it becomes 3, this can cause a concurrency exception.

Commands and domain events are usually one-to-one relationships, and when a command is invoked , the domain model initiates and stores an event. field events are the cornerstone of event traceability, which differs from events across multiple boundary contexts (bounded context), often with finer granularity and only the minimum amount of information required. Therefore, it is not a tool suitable for integration between different boundary contexts. In addition to using an in-process event bus, M-r also uses an in-memory event store. The essence of this storage is a hash table that uses the ID of the model as the key and keeps track of any events that occur in the model.

For more information about CQRS and event traceability, you can read the Mini book by Greg Young.