CQRS and Event Sourcing for Java Developers
•
41 likes•16,315 views
This document discusses CQRS and event sourcing patterns for Java developers. It begins with an overview of classical monolithic architectures versus modern microservice architectures. It then contrasts CRUD with CQRS, explaining that CQRS separates reads from writes by using commands for writes and queries for reads. Events evolve from commands and represent things that occurred in the past. The document provides an example implementation using the Lagom framework that demonstrates separating the write side from the read side and persisting events. It emphasizes that with this approach, all state changes are stored as events and the current state can be recreated by replaying events. The document encourages the use of Lagom due to benefits like asynchronous programming, developer productivity, and production readiness.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to CQRS and Event Sourcing for Java Developers
Similar to CQRS and Event Sourcing for Java Developers (20)
More from Markus Eisele
More from Markus Eisele (20)
Recently uploaded
Recently uploaded (20)
CQRS and Event Sourcing for Java Developers
- 1. CQRS and Event Sourcing for Java Developers @myfear blog.eisele.net https://keybase.io/myfear
- 2. • Classical architectures and modernization • CRUD vs. CQRS • A little example • Wrapping it up Agenda
- 7. Module Module Module WebUI .JAR.JAR .JAR .JAR.JAR .JAR .JAR .JAR .JAR .JARBrowser RDBMS RDBMS RDBMS
- 9. CRUD is OK!
- 10. • For simple domain models! • Complex models start to show weaknesses • DTO vs. VO • Read vs. Write performance • Optimistic Locking • Distributed Caches but only …
- 11. But what else?
- 14. • The Command – for Writes • e.g. CreateCargo • The Query – for Reads • e.g. ListCargo Commands and Queries
- 15. Just separating reads from writes?
- 16. • The Command • handle(CreateCargo command) {…} • The Event • on(CargoCreated event) {…} Commands evolve into Events
- 17. • Occurred in the past • Changed the system state (Write operation) • CargoCreated, LegAdded, CargoRouted, … Events
- 18. WAIT! WHAT DID YOU DO TO MY ENTITIES?
- 19. • Book-keeping of changes • Contains a full history implicitly • Storing events in sequence with a strict global order (time-stamp based) • No updates or deletes. Ever! • No single “current state”. The collection of events make up the system state in any point of time. Persistent Events
- 20. • Capturing Changes instead of updating Objects JPA Entities vs. Immutable Facts
- 22. Current State is a second class citizen
- 24. • Where was my vessel last week? • Who created the shipping request? • How much cargo did we ship last year? • Which vessels have been re-routed more than twice in under an hour? Answer all kind of new questions
- 25. The read-side cargoId location Location Cargo1 1.2,3 Cargo2 1.3,2 Cargo3 1.4,1 Cargo4 2.2,5 CargoRouted(1.2,3) CargoRouted(1.3,2) CargoRouted(1.4,1)
- 27. Implementation example. A little one.
- 32. The PersistentEntity public class CargoEntity extends PersistentEntity<RegistrationCommand, RegistrationEvent, CargoState> { //... } CargoEntity.java
- 33. The write-side PersistentEntityRef<RegistrationCommand> ref = persistentEntityRegistry.refFor( CargoEntity.class, request.getId()); RegistrationServiceImpl.java
- 34. The read-side (preparation) prepareCreateTables(session) .thenCompose(a -> prepareWriteCargo(session) .thenCompose(b -> prepareWriteOffset(session) .thenCompose(c -> selectOffset(session)))); CargoEventProcessor.java
- 35. The read-side (1) private CompletionStage<Done> prepareCreateTables(CassandraSession session) { return session.executeCreateTable( "CREATE TABLE IF NOT EXISTS cargo (" + "cargoId text, name text, description text," + "PRIMARY KEY (cargoId, destination))") ); }
- 36. The read-side (2) private CompletionStage<Done> prepareWriteCargo(CassandraSession session) { return session.prepare( "INSERT INTO cargo (cargoId, name, description, " + " owner,destination) VALUES (?, ?,?,?,?)") .thenApply(ps -> { setWriteCargo(ps); return Done.getInstance(); });
- 37. The read-side (offsets?) private CompletionStage<Optional<UUID>> selectOffset(CassandraSession session) { return session.selectOne("SELECT offset FROM blogevent_offset") .thenApply( optionalRow -> optionalRow.map(r -> r.getUUID("offset"))); }
- 38. The read-side (event trigger) @Override public EventHandlers defineEventHandlers(EventHandlersBuilder builder) { builder.setEventHandler(CargoRegistered.class, this::processCargoRegistered); return builder.build(); } RegistrationEvent!
- 39. The read-side (actual persistence) private CompletionStage<List<BoundStatement>> processCargoRegistered(CargoRegistered event, UUID offset) { BoundStatement bindWriteCargo = writeCargo.bind(); bindWriteCargo.setString("cargoId", event.getCargo().getId()); bindWriteCargo.setString("name", event.getCargo().getName()); bindWriteCargo.setString("description"); //... }
- 40. WHY IS THIS SO.. complicated?
- 41. BECAUSE.. it’s lightning FAST for users!!
- 42. [info] s.c.r.i.RegistrationServiceImpl - Cargo ID: 322667. [info] s.c.r.i.CargoEventProcessor - Persisted 322667
- 43. • All data kept in memory! • All state changes stored as events • Replay events of an PersistentEntity to recreate it • Strong consistency for PersistentEntity’s and Journal-Entries • Eventual Consistency for Read Side More precisely, because:
- 44. BECAUSE.. you can do a lot more a lot easier!!
- 45. • Recreate bugs • Migrate systems • Introduce new read-sides • Process higher volumes • Extended caching scenarios For example:
- 46. BECAUSE.. the examples are based on LAGOM and it DOES A LOT MORE for you!! ..oO(you can do this with Spring / Hibernate / Java EE – your choice)
- 47. • Lagom is asynchronous by default. • Developer productivity • Build for microservices • Takes you to production • …. You’ve heard this before, but:
- 48. ..oO(you can do this with Spring / Hibernate / Java EE – your choice)
- 51. •Keep all data in memory! • Store all state changes as events • Replay all events of an actor to recreate it • Strong consistencyfor Actor (aggregate) and Journal • Eventual Consistencyfor Read Side https://msdn.microsoft.com/en-us/library/jj554200.aspx
- 53. Written for architects and developersthat must quickly gain a fundamental understandingof microservice-basedarchitectures, this freeO’Reilly reportexploresthe journey fromSOAto microservices,discussesapproachesto dismantling your monolith,and reviews the key tenets ofa Reactive microservice: • Isolate all the Things • Act Autonomously • Do OneThing, and Do It Well • Own Your State, Exclusively • Embrace AsynchronousMessage-Passing • Stay Mobile,but Addressable • Collaborate as Systems to Solve Problems http://bit.ly/ReactiveMicroservice
- 54. The detailed example inthis reportis based on Lagom, a new frameworkthat helps you follow the requirementsfor buildingdistributed,reactive systems. • Get an overview of the Reactive Programming model and basic requirementsfor developing reactive microservices • Learnhow to create base services, expose endpoints,and then connect them with a simple, web-based user interface • Understand how to deal with persistence,state, and clients • Use integration technologiesto start a successfulmigration away fromlegacy systems http://bit.ly/DevelopReactiveMicroservice
- 55. http://bit.ly/SustainableEnterprise • Understand thechallenges ofstartinga greenfield development vs tearingapart an existing brownfield application into services • Examine your business domain to see if microservices would bea good fit • Explorebest practices for automation,high availability, data separation,and performance • Align your development teams around business capabilities and responsibilities • Inspect design patterns such as aggregator, proxy, pipeline, or shared resources to model service interactions