| dc.description.abstract | Most systems today are typically using CRUD operations to handle creating, reading, updating, and deleting data. The problem with CRUD is that it every time you update or remove data you lose important business information.
This is a problem that can be solved with event sourcing. Event sourcing provides a full audit log of everything that has happened in a system. This provides traceability for the all changes that has happened. It also fits naturally into an event-driven architecture, which helps you keep a system loosely coupled. CQRS is often combined with event sourcing, this gives flexible read models when it comes to structure and scaling.
The thesis is inspired and supported by DRIW who provided the problem description. The problem was to develop an example architecture for an order system based on event sourcing, implementing a prototype of this, and figuring out what benefits event sourcing brings in this kind of system.
The result of our thesis is a prototype system, using event sourcing for data storage. This system handles simple business logic involving orders, picking, and invoicing. The prototype has been developed as a distributed system using microservice and event-driven architecture. Apache Kafka is used for publish/subscribe messaging and to provide a persistent message queue in the prototype implementation. All events saved in the event store is made available on Kafka topics that other application can subscribe to. The events received from Kafka is used to change the state of the receiving system or to update read models. This prototype also includes simulator applications that simulate user interaction with the system.
Event sourcing is a very interesting concept and combining it with CQRS it allows you to disconnect the write model from the read model. This can help avoid the difficulties of mapping normalized database rows to objects, by having read models in the format you require. If you have complex queries that are difficult to perform on your read model you can always create a new read model optimized for this query.
Event sourcing is more complex than the CRUD approach to data storage. Therefore, CRUD is most likely the better option if you don’t require an audit log and are not developing an event-driven system. Event sourcing combined with CQRS gives an eventually consistent read model. This is not strictly bad but is something the developer need to be aware of.
We ended up with a solid prototype of a distributed ordering system by using event sourcing and CQRS along with microservice and event-driven architecture.
The prototype received very positive feedback from DRIW. We found two benefits of event sourcing that interested them. That it provides traceability and it fits naturally into an event-driven architecture. | nb_NO |
