Event-Sourcing - CQRS With Event Sourcing (State Olay Tarihçesi Olarak Saklanır)

Giriş
Event Sourcing, Command Query Responsibility Segregation - CQRS kullanımında zirveyi temsil ediyor ve genellikle optional olarak düşünülüyor.

Şeklen şöyle. Burada artık sadece "Write Data Store" şeklinde bir veri tabanı yok. Olayları tarihçe olarak saklayan bir "Event Store" var.

Event Sourcing Nedir
Açıklaması şöyle.

"Event sourcing", ..., means storing state as a history of events. The event store replaces the RDBMS that we might normally use to remember our history. The history, as represented in an event store, is an append only sequence of events that describe how an entity has changed over time.

Veri tabanı açısından açıklaması şöyle.

In the world of an O/RM, how do we remember where we are? Typically, when new information arrives, we load our own memory from the database, integrate the new information, and then store our new memory into the database (replacing the old). The old memory is loaded, the new memory is calculated. We store the new memory, and when we next need it, that memory is loaded.

With event sourcing, this basic protocol is unchanged - the significant difference is that we don't replace the old memory, but append new changes to it.

Açıklaması şöyle

Well, it is not a maturity level but another practice that fits with CQRS. Your commands are using the writing model to modify the write storage. Instead, your commands produce application events. These events stored into a log and can be used to replay the history of a database and eventually restore it.

...

The usage of Event Sourcing is totally optional to CQRS.

Yani CQRS-ES kullanılınca, nesneler event kullanarak haberleşiyorlar. Açıklaması şöyle.

CQRS is also an enabler for event-based programming models. It’s common to see CQRS system split into separate services communicating with Event Collaboration. This allows these services to easily take advantage of Event Sourcing.

Event Sourcing Ne Zaman Kullanılabilir

Açıklaması şöyle

1. Scenarios where the volume of read operations is significantly higher than write operations.

2. Where one team of developers can focus on the write side and another team can focus on the read side. There is nothing limiting CQRS to a single read-side: multiple independent read projections may coexist, and therefore, multiple teams may be assigned to the task.

3. Cases where the access patterns for writing vary significantly from those for reading. For example, transactional writes vs reporting and analytics on the read side.

Event Store ve Son State

Açıklaması şöyle. Normalde son state'e ihtiyaç duymayan durumlarda Event Store güzel bir çözüm. Örneğin Audit Log gibi şeylerde zaten son state çok önemli değil.

The important point though is that there is no “current-state” of domain. The current state is a derived state which can be achieved by replaying the events on an aggregate. Event sourcing provides a implicit audit log of changes as a set of domain events. On the other side, since there is no entity state, it is not possible to query for an entity in the command event store.

Ancak son state gerekiyorsa, "Event Store" u yine "Read Data Store" ile istenirse senkronize ediliyor. Ancak bu senkronizasyon için kod yazılıyor, çünkü Read tarafında işlenmiş/değiştirilmiş veri gerekiyor.

Ayrıca şu duruma da dikkat etmek lazım. Event Store'a yazan kod da son state'e ihtiyaç duyabilir. Bu aslında istisnai bir durum ama karşımıza çıkabilir. Açıklaması şöyle. Read Data Store'dan okuma yapılacaksa "strong consistency" beklememeli. 

What if command service needs to read some entity data? Ideally it should not depend on a previous state since all command service should do is an append-only log of commands (the choice of event store i.e. messaging vs DB is of less significance for this point). But what if? Can the command service also read the query store projection? The answer is contextual and may be it can, but there is an eventual consistency at play here. As long as as command processing does not depend of strong consistency guarantees of data it needs to read, it should fine to read. Probably keeping this as an edge case is prudent.

Örnek

Amazon Web Service kullanıyorsak şeklen şöyle

"Event Store" olarak kullanılan DynamoDB'ye Stream takılabiliyor. Bu Stream'i dinleyen Lambda metodlar event verisini dönüştürerek "Read Data Store" üzerinde saklıyor. Açıklaması şöyle

DynamoDB has a functionality called Streams, which publishes item level modifications to data in a table. A Lambda can then be configured to subscribe to these events, persisting them in an appropriate format to an RDS read data store.

Event Sourcing ve Domain Driven Design İlişkisi

Eğer Domain Driven Design uyguluyorsak, Event Sourcing tabi ki, Bounded Context içinde kullanılıyor. Açıklaması şöyle.

Event Sourcing is an architectural pattern that is applied within a Bounded Context to provide a single source of truth. 

Bir başka açıklama şöyle. Domain Events yazısına bakabilirsiniz.

Event Sourcing is when you use Domain Events to store the state of an Aggregate within a Bounded Context.

This basically means replacing your relational data model (or other data stores) with an ever-growing log of Domain Events, which is called an event store. This is the core of Event Sourcing.