{"id":153,"date":"2020-02-12T12:58:32","date_gmt":"2020-02-12T12:58:32","guid":{"rendered":"https:\/\/www.kindsonthegenius.com\/microservices\/?p=153"},"modified":"2020-02-12T12:58:32","modified_gmt":"2020-02-12T12:58:32","slug":"understanding-the-architecture-of-event-based-cqrs-design","status":"publish","type":"post","link":"https:\/\/www.kindsonthegenius.com\/microservices\/understanding-the-architecture-of-event-based-cqrs-design\/","title":{"rendered":"Understanding the Architecture of Event-Based CQRS Design"},"content":{"rendered":"

In this article, I am going to explain the various components of a simple Event-based CQRS Architecture<\/strong>.<\/p>\n

 <\/p>\n

Take a look at Figure 1<\/p>\n

 <\/p>\n

\"\"<\/a>
Figure 1: Event-Based CQRS Architecture<\/figcaption><\/figure>\n

 <\/p>\n

Controller<\/strong>: This is also called the UI Controller. It is responsible for\u00a0 intercepting both read and write operations comming from the client. So when you enter a url in your browser, and and hit <Enter>, the request immediately routes to the controller<\/p>\n

Commands<\/strong>: Whatever request is coming from the controller could either be a command or a query.\u00a0 A command represents\u00a0 an intent to modify the state of an entity. This is normally in form of a DELETE, POST or PUT request<\/p>\n

Command Gateway<\/strong>: A Command Gateway provides an interface for choosing how to dispatch your commands. Normally, the command coming from the controller ges to the CommandGateway. It could dispatch the command either synchronoously or asznchromously.<\/p>\n

Command Handler<\/strong>:\u00a0 A command handler receives and responds to specific type of commands. It then executes some business rule or logic based on the command. It retrieves the domain enities and make the neccesary changes on them.<\/p>\n

Domain Entity<\/strong>: Domain Entities are aggregate entities that are modeled to reprsent the state of the components in the domain. An aggregate<\/strong> is an entity or group of entities that are always kept in a consistent state. For example, an Employee entity could be an aggregate. It could have additional aggregates like Address, NextOfKin etc. If the state of an aggregate changes, then a dmain event is generated.<\/p>\n

Repository<\/strong>: A repository just as you may know provides functionality for managing aggregates. For example, a repository helps you find, save or delete an aggregate. A repository, could interface with a persistent storage(like a database) to store the aggregates. A repository could also use an event store to call up and aggregate and recreate it\u2019s state at any point in history based on saved states.<\/p>\n

Event Store:<\/strong> This is a storage of all the changes that have been applied to an entity. It is like a history of events. An event store can replay\u00a0these historical changes and therefore rebuild the state of an entity at any point in time. Event store may also use a database for event storage.<\/p>\n

Event:<\/strong> An event is a notification that there has been a change to the state of an entity. So when an update is made, then an event is emitted to say, what changes actually took place.<\/p>\n

Event Bus:<\/strong> This is like a channel for generated events. They are normally backed up by a messaging topic in a publish\/subscribe manner.<\/p>\n

Event Handler:<\/strong> These are methods the receive events and handle the events. For example, when an event is emited for an update to an entity, then an event handler recieves this event from the event bus. It could then update the WriteDB by mirroring this changes to materialized views.<\/p>\n

Query:<\/strong>\u00a0 Think of a query as the opposite of a command. A query is a request for data without making and changes. When a query comes from the controller, it is routed to the query manager. Then the query manager manager executes the query and returns the results the to client.<\/p>\n

 <\/p>\n

I recommend you follow this tutorial on building an\u00a0CQRS-based application<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

In this article, I am going to explain the various components of a simple Event-based CQRS Architecture.   Take a look at Figure 1   … <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12,27,2,1],"tags":[6,8],"class_list":["post-153","post","type-post","status-publish","format-standard","hentry","category-axon","category-axonframework","category-microservices","category-uncategorized","tag-cqrs","tag-event-sourcing"],"_links":{"self":[{"href":"https:\/\/www.kindsonthegenius.com\/microservices\/wp-json\/wp\/v2\/posts\/153","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kindsonthegenius.com\/microservices\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kindsonthegenius.com\/microservices\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kindsonthegenius.com\/microservices\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kindsonthegenius.com\/microservices\/wp-json\/wp\/v2\/comments?post=153"}],"version-history":[{"count":3,"href":"https:\/\/www.kindsonthegenius.com\/microservices\/wp-json\/wp\/v2\/posts\/153\/revisions"}],"predecessor-version":[{"id":157,"href":"https:\/\/www.kindsonthegenius.com\/microservices\/wp-json\/wp\/v2\/posts\/153\/revisions\/157"}],"wp:attachment":[{"href":"https:\/\/www.kindsonthegenius.com\/microservices\/wp-json\/wp\/v2\/media?parent=153"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kindsonthegenius.com\/microservices\/wp-json\/wp\/v2\/categories?post=153"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kindsonthegenius.com\/microservices\/wp-json\/wp\/v2\/tags?post=153"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}