Download as PDF, PPTX
![[info] s.c.r.i.RegistrationServiceImpl - Cargo ID: 322667.
[info] s.c.r.i.CargoEventProcessor - Persisted 322667](https://image.slidesharecdn.com/cqrs-for-java-developers-160629015220/75/CQRS-and-Event-Sourcing-for-Java-Developers-42-2048.jpg)
Uploaded byMarkus Eisele
CQRS and Event Sourcing for Java Developers
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.
More Related Content
Similar to CQRS and Event Sourcing for Java Developers
CQRS and Event Sourcing for Java Developers
- 1. CQRS and EventSourcing 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
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 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.
- 12.
- 13.
- 14. • The Command – for Writes •e.g. CreateCargo • The Query – for Reads • e.g. ListCargo Commands and Queries
- 15. Just separating readsfrom writes?
- 16. • The Command • handle(CreateCargocommand) {…} • 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 YOUDO 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 Entitiesvs. Immutable Facts
- 22. Current State is asecond class citizen
- 23.
- 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 Cargo11.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)
- 26.
- 27.
- 28.
- 29.
- 31.
- 32. The PersistentEntity public classCargoEntity 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) privateCompletionStage<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) privateCompletionStage<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?) privateCompletionStage<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 (eventtrigger) @Override public EventHandlers defineEventHandlers(EventHandlersBuilder builder) { builder.setEventHandler(CargoRegistered.class, this::processCargoRegistered); return builder.build(); } RegistrationEvent!
- 39. The read-side (actualpersistence) 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 THISSO.. complicated?
- 41. BECAUSE.. it’s lightning FASTfor 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 doa 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 arebased 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 dothis with Spring / Hibernate / Java EE – your choice)
- 49.
- 50.
- 51. •Keep all datain 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
- 52.
- 53. Written for architectsand 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 exampleinthis 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 thechallengesofstartinga 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