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.

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

3. Classical Architectures

4. Application Server
EAR - Enterprise Archive
RESTMobile
Web
UI
.JAR.JAR
.JAR
.JAR.JAR
.JAR
.JAR
.JAR
.JAR
.JAR
Browser RDBMS

5. Application Server
Application Server
Application Server
EAR - Enterprise Archive
RESTMobile
Web
UI
.JAR.JAR
.JAR
.JAR.JAR
.JAR
.JAR
.JAR
.JAR
.JAR
Browser RDBMS

6. Modernization

7. Module
Module
Module
WebUI
.JAR.JAR
.JAR
.JAR.JAR
.JAR
.JAR
.JAR
.JAR
.JARBrowser RDBMS
RDBMS
RDBMS

8. Routing Module
Tracking Module
Order Module
Tracker UIBrowser HistoryDB
Order DB
RoutesDB

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?

12. Complexity of Domain Model
Effort to change / enhance
CRUD
CQRS

13. • Command Query Responsibility Segregation
CQRS

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

23. • Capturing Changes instead of updating Objects
The read-side

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)

26. Neo4J
Cassandra
Cassandra

27. Implementation
example. A little one.

28. Cargo Tracker
https://github.com/lagom/activator-lagom-cargotracker

29. Registration
Shipping
Frontend Cassandra

31. restCall(Method.POST, "/api/registration",
register()
),
restCall(Method.GET, "/api/registration/all",
getAllRegistrations()
),
Write-Side
Read-Side

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)

49. Links and further
reading

50. Project Site:
http://www.lightbend.com/lagom
GitHub Repo:
https://github.com/lagom
Documentation:
http://www.lagomframework.com/documentation/1.0.x/java/Home.html
Cargo Tracker Example:
https://github.com/lagom/activator-lagom-cargotracker

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

52. https://www.infoq.com/minibooks/domain-driven-design-quickly

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