[Forward] in simple terms EventSourcing and CQRS

From

Author: Mu class network - desert wind

Address: http://www.imooc.com/article/40858

basic introduction

Event Sourcing , also known as event source, is another increasingly popular concept these years, is an architectural pattern Martin Fowler proposed by the god. In simple terms, it has the following characteristics:

The entire system is event-driven, event-driven by all business is done.
Events are first-class citizens, data event-based system, some kind of event you want to save on storage.
Just some business data generated by the event view, not necessarily to be saved to the database.

What is Event Sourcing

That might be quite difficult to understand, let's give chestnuts. This is an example of an account balance management:

In this figure, in the middle of our account object, it has several time processing functions create(), deposit(), withdraw(), respectively, for operating the new account process, account deposits and withdrawals.

Is one of the events on the left, it is a stream of events, according to a user request or produce from elsewhere. In the example here, among them, three events: AccountCreated, AccountDeposited, AccountWithdrawed, correspond to account creation event, the event deposits and withdrawals of events. When the event occurs, we will trigger above the corresponding handler Account object.

After the Account object on the right is finished with four events left, the most recent data state. Specific process is:

The system generates a new account of the event AccountCreated, Accountobject to handle this event, the event inside the Id is 1234, the system first try to find the id 1234 accounts and found no, then create a new Accountobject and it calls the above create()processing functions, but also id is initialized and balances.
Then, there is a AccountDepositedevent, the corresponding Accountobject id is 1234, the system finds objects created before, on top of it application deposit()operation processing function, which is an increase of balances, update the account balance.
The system also received a deposit events, like the above, once the balance has been updated.
Receive a cash event, or find the account id is 1234, it calls in the above withdraw()handler, to make a withdrawal, updates the balance.
Finally, 1234 the balance of the account is 200, that is, the right of the state data.

When the same time, these events require above persisted in a database or elsewhere, the data does not need to save the state account, we just need to get account the current state of the data, by this account related events, call their handlers regenerate the current status. Of course, every such call handler will inevitably lead to waste of resources, because it needs to get all this account of events from the database, and then in turn call handler. So in general we can put the latest status of this account, in a way to save the view in the database.

The above process and the way that we say the Event Sourcing, also based processing mode for the event source.

Event Sourcing composition

By the example above, we understand the Event Sourcing (event traceability), let's look at which parts of the Event Sourcing included.

Aggregate object

In the above example, Accountthe object is an aggregate object, it contains basic account information, when the processing method also includes the account operation, i.e. several event handlers. Learn Domain Driven Design people should think of this time, the Account object is actually a domain model, Account field model requires business operations, provided by its own.

Each object has a polymerization Id, uniquely identifies the object, so the system will have different accounts in different Account object.

Event Store

We say, among the Event Sourcing mode, all events are to be saved to the database (or other storage, the following direct that the database) in this store called Event Store.

Each event should also contain polymeric object id it to be processed, and the order of events, when the query is to find the relevant events from the database according to the object id of the polymerization, and sorted by serial number or the generated event.

Event Store In addition to providing event data storage, query function, can also provide other functions to reproduce the event. Recurring events, is one of the cut-off time of all the events taken out, calls his handler, then generate business status that point in time. So before reproduce, if the state of our business data, stored in the form of views into the database, we need to clear the corresponding data. It is for this event-source characteristics of Event Sourcing mode, so we can hope to offer such historical reproduction function.

Polymerization repository

In general, our data state of the aggregate object is not stored among databases. Whenever a system to obtain data of a certain account, are removed from the Event Store event among all relevant aggregate object, then call the approach of these events in order, "polymerization" the latest target in the field of data states. This is the aggregation function library requires resources provided.

view

Above we have said, if every time again "aggregate" the object to get the current status, will waste a lot of resources. Therefore, we can at the time an event occurs, this latest data aggregation state of the object, written to a table, the table can be called materialized views.

Inquire

Because we offer a special view of the table, the aggregate object date stored in the database, then we in the query, the query can go through the materialized view, rather than the aggregate object repository to query.

Event Sourcing and CQRS

CQRS, is Command Query Responsibility Segregation acronym, also known as the isolate to read and write. In the above, we say, for performance reasons, the polymerization state of the object data stored in the form of materialized view, may be used to query the data, that is, we update the query process data isolate. We update the state of the event data by the aggregate object, and treated in the same event by another processor to update the data in the materialized view.

So, Event Sourcing and CQRS have a natural link, so often someone will put them together to discuss. In fact the case, CQRS in later use Event Sourcing mode, and the use of materialized views, additional benefits generated.

The figure is good to use after Event Sourcing CQRS a simple flow pattern:

Command for the type of request (data needs to be modified), updating Web layer will go through the object Event Sourcing polymerization process, then there will be a processing Event Handler corresponding event listener class, to update the materialized view.
Query for the type of request, web layer retrieves data returned by respective DAO.

Advantages and disadvantages of Event Sourcing

Event Sourcing reason why more and more attention, because some of its advantages:

Facilitate traceability and history to reproduce
this "traceability" means that we can save through the analysis of the events, know the state of the current system, is step by step how to become like this. This is especially useful in a large business complex applications systems. If you do not use Event Sourcing mode, even if we use a complete log mechanism to provide log analysis, it is difficult to retroactively change the process data.
In addition, we can based on historical events, regenerate all the service status data. We can even specify I want to generate some point to specific state. It is as if we are free shuttle in the process of running our system, view the status of any point of time.
Bug's easy to fix
because we can reproduce the history, so when a bug was found in the future, we can later renovating, re-direct our business data aggregation, repair our data. If you are using traditional design methods, we need to pass SQL or write a program to modify the database manually, in order to bring it to a normal state. If there is this bug longer, involve more data, this would be a very troublesome thing.
In addition, we can process business through event analysis, it can often help us find the problem.
Can provide very good performance
in Event Sourcing mode, saving the event data is a table write operation has been added, not updated. This can provide a very good write performance, in many cases, so that the throughput of the system receives an event can be high.
Then aggregate object according to the aggregation Id event, access to all the relevant events, "polymerization" the object, call business methods. But its results and do not need to write database, there is only a read operation, other operations are in memory.
Finally, to deal with these events by another Event Handler, update the table materialized view. In updating the data, we just need to lock records, so this process can be quickly updated.
In this mode, the pressure of our system basically fall on the final database, the entire system will not have too many locks and wait (only processed on the same aggregate object concurrency, will wait, for example, a user simultaneously issued a plurality of requests for deposit withdrawal operation), can provide a very good throughput.
Easy to use data analysis system
that is quite clear, with the Event Sourcing model, our data is the event, we just need to approach the existing events plus the need to do data analysis; or send the event directly to an analysis system. We do not need to do data analysis, and then define a variety of events, such as sending events in the system.

Of course, it also has some disadvantages:

Change development thinking of
the greatest difficulty, estimated that the change of way of thinking of the developers. Use Event Sourcing model, we need to design point of view, to use a certain domain-driven design, from the development point of view, we need to use event-based reactive programming thinking. Accustomed to the traditional object-oriented programmers, this is not a small challenge.
No sophisticated framework for
us to develop Java applications, in most cases will now use Spring, a large part using Spring MVC (or Spring Boot). Anyway, are developed based on the Spring framework family. However, Event Sourcing mode, it has not been a large and unified framework, both to improve to achieve good Event Sourcing mode, but also widely accepted, there are some manufacturers can best improve business services, ensure that the entire ecology the healthy development.
Change the structure of the event
using the Event Sourcing mode, there is a problem is to change the structure of the event. Due to changes in the business, we have designed the event, there may be some changes in the structure, may need to add some data, or delete some data. So this time, just want to say "reproduce history" will be a problem. Then we need some way to provide him with compatibility.
From the perspective of system design domain model rather than a database table based design
which is actually not a disadvantage, but due to domain-driven design software design approach is not widely used, many developers do not understand this, the corresponding design and development methods not familiar with, so this has become a problem to use Event Sourcing model development need to be addressed.
Domain Driven Design from business analysis, from the domain model design set out to design a system, and in the design of a system based on Event Sourcing model, we often have to use some areas of model design method, starting from the domain model design, designing aggregations object and its business (event), and the processing method (event Handler). By domain-driven design of complex applications systems often provide a better design. However, this design approach and our common design approach is inconsistent with certain learning and practice costs.

Event Sourcing based distributed systems

If you want to develop a model based on Event Sourcing distributed system, the easiest way is to use two services provide read and write functions, respectively. Write Command service receives the request, triggering a polymerization process on the object function, to update the aggregate data. Then sends this event to a MQ queue. Service monitor read this queue, get events, updating data corresponding materialized view. Query requests are simultaneously read all of the service process and return.

For writing services, its data only event, is a stream of write operations, as well as index-based queries. For a read service, we can deploy multiple applications, providing further performance data queries. It can be seen separated by such a simple reading and writing, we can greatly improve system performance.

When to use Event Sourcing

Use Event Sourcing has its advantages and disadvantages, so when to use Event Sourcing model?

The first is the type of system, if your system has a large number of CRUD, which is CRUD type of business, it is not suitable to use Event Sourcing mode. Event Sourcing mode is more suitable for complex business applications.
If you or your team there DDD (Domain Driven Design) related personnel, then you should give priority to use Event Sourcing.
If your systems, business process data generated is more important than the result, or the more meaningful, it should use Event Sourcing. You can use Event Sourcing event data to analyze process data generated to address the bug, it can also be used to analyze the user's behavior.
If you need the system to provide state of the business version of history, such as a content management system, if I want to achieve for the content version management, version rollback and other operations, you should use Event Sourcing.