CQRS and Event Sourcing for Java Developers Markus Eisele

Transcription

1 CQRS and Event Sourcing for Java Developers Markus Eisele

2 @myfear

3 Agenda Classical architectures and modernization CRUD vs. CQRS A little example Wrapping it up

4 Classical Architectures

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

6 > Traditional application architectures and platforms are obsolete. -- Gartner

7 More users Reactive Manifesto Microservices Akka RoR Spring J2EE

8 New requirements Rather than acting on data at rest, modern software increasingly operates on data in near real-time. Shortened time-frames for putting changes into production New business models evolve from existing ones New questions need to be answered by existing applications Datacenter costs need to go down constantly

9 Which best describes the amount of data that your organization is dealing with, compared to two years ago? 14% 2% We are dealing with MORE data We are dealing with the SAME AMOUNT of data 84% We are dealing with LESS data

10 Application Server Application Server Application Server EAR - Enterprise Archive Web UI Mobile REST Browser.JAR.JAR.JAR RDBMS.JAR.JAR.JAR.JAR.JAR.JAR.JAR

11 Modernization

12 Module.JAR.JAR.JAR RDBMS Module Browser WebUI.JAR.JAR.JAR RDBMS Module.JAR.JAR.JAR.JAR RDBMS

13 Order Module Order DB Browser Tracker UI Tracking Module HistoryDB Routing Module RoutesDB

14 How do Microservices lead to CQRS?

15 Order Module Order DB Cargo Cargo Order Tracker UI Tracking Module HistoryDB Routing Module RoutesDB

16 Order Service createorder() readorder() Order DB Cargo Order OrderID -Name.. putohist() getorder() Tracking Service createohist() readohist() HistoryDB Order History OHistID -Name -OrderID...

17 Microservices decrease consistency All services own all relevant data Updates to other services might be delayed Redundant data is saved in various places Is it consistent? What happens when an order was created but no history entry? Synchronous and blocking? OR asynchronous calls?

18 Event Sourcing and CQRS to the rescue

19 Order Service Order DB Cargo Cargo Order Publish OrderCreated Tracking Service HistoryDB History Entry History Entry History Entry MessageBroker Subscribe OrderCreated

20 Advantages of ES Event-driven architecture and makes it possible to reliably publish events whenever state changes. Mostly avoids the object-relational impedance mismatch. Reliable audit log of the changes made to a business entity Temporal queries that determine the state of an entity at any point in time. Event sourcing-based business logic consists of loosely coupled business entities that exchange events.

21 Challenges of ES It is a different and unfamiliar style of programming and so there is a learning curve. The event store is difficult to query since it requires typical queries to reconstruct the state of the business entities. That is likely to be complex and inefficient. As a result, the application must use Command Query Responsibility Segregation (CQRS) to implement queries. This in turn means that applications must handle eventually consistent data.

22 CQRS Command Query Responsibility Segregation CQRS means separating command responsibilities from query responsibilities.

23 CRUD is OK!

24 For simple domain models! but only Complex models start to show weaknesses DTO vs. VO Read vs. Write performance Optimistic Locking Distributed Caches

25 But what else?

26 Effort to change / enhance CQRS CRUD Complexity of Domain Model

27 Commands and Queries The Command for Writes e.g. CreateCargo The Query for Reads e.g. ListCargo

28 Just separating reads from writes?

29 Commands evolve into Events The Command handle(createcargo command) { } The Event on(cargocreated event) { }

30 Events Occurred in the past Changed the system state (Write operation) CargoCreated, LegAdded, CargoRouted,

31 WAIT! WHAT DID YOU DO TO MY ENTITIES?

32 Persistent Events 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.

33 JPA Entities vs. Immutable Facts Capturing Changes instead of updating Objects

34

35 Current State is a second class citizen

36 The read-side Capturing Changes instead of updating Objects

37 Answer all kind of new questions 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?

38 The read-side CargoRouted(1.2,3) Location cargoid location CargoRouted(1.3,2) CargoRouted(1.4,1) Cargo1 1.2,3 Cargo2 1.3,2 Cargo3 1.4,1 Cargo4 2.2,5

39 Neo4J Cassandra Cassandra

40 Implementation example. A little one.

41 Cargo Tracker

42 Registration Frontend Cassandra Shipping

43

44 Write-Side restcall(method.post, "/api/registration", register() ), restcall(method.get, "/api/registration/all", getallregistrations() ), Read-Side

45 The PersistentEntity CargoEntity.java public class CargoEntity extends PersistentEntity<RegistrationCommand, RegistrationEvent, CargoState> { //... }

46 The write-side RegistrationServiceImpl.java PersistentEntityRef<RegistrationCommand> ref = persistententityregistry.reffor( CargoEntity.class, request.getid());

47 The read-side (preparation) CargoEventProcessor.java preparecreatetables(session).thencompose(a -> preparewritecargo(session).thencompose(b -> preparewriteoffset(session).thencompose(c -> selectoffset(session))));

48 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))") ); }

49 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(); });

50 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"))); }

51 The read-side (event public EventHandlers defineeventhandlers(eventhandlersbuilder builder) { builder.seteventhandler(cargoregistered.class, this::processcargoregistered); return builder.build(); } RegistrationEvent!

52 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"); //... }

53 WHY IS THIS SO.. complicated?

54 BECAUSE.. it s lightning FAST for users!!

55 [info] s.c.r.i.registrationserviceimpl - Cargo ID: [info] s.c.r.i.cargoeventprocessor - Persisted

56 More precisely, because: 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

57 BECAUSE.. you can do a lot more a lot easier!!

58 For example: Recreate bugs Migrate systems Introduce new read-sides Process higher volumes Extended caching scenarios

59 BECAUSE.. the examples are based on LAGOM and it DOES A LOT MORE for you!!..oo(you can try with Spring / Hibernate / Java EE your choice)

60 You ve heard this before, but: Lagom is asynchronous by default. Developer productivity Build for microservices Takes you to production.

61 ..oo(you can do this with Spring / Hibernate / Java EE your choice)

62 When not to.. do CQRS?

63 Don t do CQRS when you don t want eventual consistency. have to do deletes. (It gets messy) have no idea about your domain. just have to store and retrieve a value..

64 Links and further reading

65 Project Site: GitHub Repo: Documentation: Cargo Tracker Example:

66 Keep all data in memory! Store all state changes as events Replay all events of an actor to recreate it Strong consistency for Actor (aggregate) and Journal Eventual Consistency for Read Side

67

68 Written for architects and developers that must quickly gain a fundamental understanding of microservice-based architectures, this free O Reilly report explores the journey from SOA to microservices, discusses approaches to dismantling your monolith, and reviews the key tenets of a Reactive microservice: Isolate all the Things Act Autonomously Do One Thing, and Do It Well Own Your State, Exclusively Embrace Asynchronous Message-Passing Stay Mobile, but Addressable Collaborate as Systems to Solve Problems

69 The detailed example in this report is based on Lagom, a new framework that helps you follow the requirements for building distributed, reactive systems. Get an overview of the Reactive Programming model and basic requirements for developing reactive microservices Learn how 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 technologies to start a successful migration away from legacy systems

70 Understand the challenges of starting a greenfield development vs tearing apart an existing brownfield application into services Examine your business domain to see if microservices would be a good fit Explore best 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

71

72