Time Information • No updates / deletes, only append • Who now which data will be valuable in the future? • State is a first class derivative What changes?
of the current state of your application • Created as a left fold of your Event Stream in historical order • You can create as many Readmodels as you want for a single Event Stream • Readmodel persistence is independent from your Events, e.g. • InMemory for business decisions • Redis for short caches • SQL or NoSQL Databases for Views Readmodels
pattern separate reading from writing operations • Your operation has return type void? -> Command • Your operation returns any value? -> Query • Queries must not change any state of your app • When you execute a query many times, the result has to be the same. (Assumed no other operations happened) Not much more as simple Pattern
one or many Events • The EventStore is the single source of truth • ReadModels could be used for business decisions(*) • Queries using Readmodels to return application state How they work together
are used to implement the CQRS pattern • Beside a Command- and QueryBus you can use an EventBus to trigger some kind of Side Effect • An EventBus publish persisted (Domain) Events, so you can listen for it and execute related logic, for example • send a Registration E-Mail • trigger another related service to your event (Purchase- and Billing Service) EventBus / ProcessManager / Saga - you named it
expensive, you can create snapshot but you also have to manage them • Creating Readmodels asynchronously can lead to concurrency problems • Events are immutable but in some cases like GDPR (DSVO) you have to anonymize Data • Event Sourcing with Files need additional work Event Sourcing is perfect, isn’t it? - Almost
Example with TypeScript, NestJS • Hosted Example http://event-sourcing-example.webdev-jogeleit.de/ • EventStore https://github.com/fjogeleit/event-store Bank Account API