The Building Blocks of an Event Driven CQRS Application in Scala

In this talk we will have a look at the basic building blocks we need when developing an Event Driven CQRS application in Scala.

We will discuss some design choices and challenges we may encounter and how to tackle them using the Scala Type System and some functional programming techniques.

We'll explore the following topics:

- Defining an Aggregate and its Protocol (Commands and Events) in the form of case classes (obviously!);

- Using Future and Try to express computations;

- Implementing an Aggregate by means of BehaviorDsl based on its Protocol and PartialFunctions;

- How to glue them all together to produce a write and a read model;

Finally, we will have a look on how to integrate it with Akka and Akka Persistence.

Transcript

1. Fun.CQRS Functional and Fun CQRS in Scala
2. Agenda DDD / CQRS / Event Sourcing Aggregates / Commands / Events in Scala Akka and asynchrounous programming Akka Persistence and Event Sourcing
3. Not About Akka Typed "Function and Reactive Domain Modeling" - Debasish Ghosh
4. DDD / CQRS / ES Aggregate is a DDD concept. It has a root and zero or more entities and value objects underneath Commands and Events are used in CQRS Events can be persisted and replayed
5. Event Driven / Sourcing CQRS is Event Driven, but not necessarily implements Event Sourcing in synchronous CQRS: tx(Cmd ⇒ Aggregate ⇒ Event ⇒ View) in asynchronous CQRS: tx(Cmd ⇒ Aggregate ⇒ Event) tx(Event ⇒ View)
6. Scala And CQRS On creation C m d = > E v e n t E v e n t = > A g g r e g a t e / / t h e r e f o r e w e h a v e C m d = > ( A g g r e g a t e , E v e n t ) Post-creation ( A g g r e g a t e , C m d ) = > S e q [ E v e n t ] ( A g g r e g a t e , E v e n t ) = > A g g r e g a t e / / t h e r e f o r e w e h a v e ( A g g r e g a t e , C m d ) = > ( A g g r e g a t e , S e q [ E v e n t ] )
7. Async API On creation C m d = > F u t u r e [ E v e n t ] E v e n t = > A g g r e g a t e / / t h e r e f o r e w e h a v e C m d = > F u t u r e [ ( A g g r e g a t e , E v e n t ) ] Post-creation ( A g g r e g a t e , C m d ) = > F u t u r e [ S e q [ E v e n t ] ] ( A g g r e g a t e , E v e n t ) = > A g g r e g a t e / / t h e r e f o r e w e h a v e ( A g g r e g a t e , C m d ) = > F u t u r e [ ( A g g r e g a t e , S e q [ E v e n t ] ) ]
8. Async API - Inconvenience On creation ( c m d : C r e a t e F o o ) = > F u t u r e . s u c c e s s f u l ( F o o C r e a t e d ( " f o o " ) ) Post-creation ( f o o : F o o , c m d : C h a n g e N a m e ) = > F u t u r e . s u c c e s s f u l ( S e q ( F o o N a m e C h a n g e d ( " b a r " ) ) )
9. Sync/Async API - Lift On creation C m d = > E v e n t C m d = > F u t u r e [ E v e n t ] / / Y e a h ! ! C m d = > T h r o w a b l e Post-creation ( A g g r e g a t e , C m d ) = > E v e n t ( A g g r e g a t e , C m d ) = > S e q [ E v e n t ] ( A g g r e g a t e , C m d ) = > F u t u r e [ E v e n t ] ( A g g r e g a t e , C m d ) = > F u t u r e [ S e q [ E v e n t ] ] / / Y e a h ! ! ( A g g r e g a t e , C m d ) = > T h r o w a b l e
10. Akka And DDD/CQRS Is the Aggregate an Actor? Or does it live inside an Actor? If it lives inside an Actor, the Actor must know it’s hosting an Aggregate Akka Persistence for Event Sourcing Akka Persistence Query for generating Views (experimental)
11. Protocol And Behavior Protocol is the set of commands and events for a given Aggregate Behavior is the implementation Conditions to accept commands Possible failures Modify Aggregate state
12. Protocol And Behavior ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ A g g r e g a t e │ │ P r o t o c o l │ │ │ ├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ │ t y p e P r o t o c o l │ │ C o m m a n d s │ │ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘ ├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘ │ │ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤ │ │ E v e n t s │ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ B e h a v i o r [ A g g r e g a t e ] │ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
13. AggregateManager Create AggregateActors by id Forward messages to right AggregateActors ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ A g g r e g a t e M a n a g e r │ ─ ─ ─ ─ ─ ┐ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘ │ │ │ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ A g g r e g a t e A c t o r ├ ─ ┐ └ ┬ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘ ├ ─ ┐ └ ─ ┬ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘ │ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
14. AggregateActor AggregateActor is initialized with Behavior of Foo Responsible for Foo lifecycle and events storing ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ A g g r e g a t e A c t o r │ ─ ─ ─ ─ ─ ─ ─ ┐ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘ │ │ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ B e h a v i o r [ F o o ] │ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘ Protocol messages are sent to Actor and applied to Aggregate through its Behavior
15. Projections We read from the Event Store to produce Views Akka Persistence Query new experimental module Produces a Reactive Stream source with the selected events
16. Shop Aggregates Customer just info from a customer Product create, change name and change price Order (references Customer and Products by identifier) created for a customer add / remove products execute / cancel
17. Shop Projections Customer Aggregate event → CustomerView Product Aggregate event → ProductView Customer, Product and Order events → OrderView
18. Problem With OrderViewProjection What to do with Events from Customer and Product? They will probably arrive before the first order is created. Should we query the CustomerViewRepo and ProductViewReop whenever we need more info? Will they reflect the expected state?
19. Solutions 1. Have one single event stream and one consumer can be a serious bottleneck 2. Implement specific logic for each single event for each view can lead to increasing complexity 3. Copy data by reusing existing projections, but saving in another Repository need for more storage, but simpler and reusable code Demo project uses that approach (check it) 4. Synchronous views, at least the main views Response time penalty, but better user feedback
20. Thank You! http://twitter.com/@renatocaval https://github.com/strongtyped/fun-cqrs