functional cqrs functional cqrs
play

Functional CQRS Functional CQRS The double engine badass @Ramtop - PowerPoint PPT Presentation

Functional CQRS Functional CQRS The double engine badass @Ramtop @Ramtop Have you ever considered Event Sourcing architecture? @Ramtop @Ramtop CQRS: When and Why Very Good for Complex mutable state Separation of logic Auditing


  1. Functional CQRS Functional CQRS The double engine badass @Ramtop @Ramtop

  2. Have you ever considered Event Sourcing architecture? @Ramtop @Ramtop

  3. CQRS: When and Why Very Good for ✔ Complex mutable state ✔ Separation of logic ✔ Auditing required ✔ Orders, Trades, Editors @Ramtop @Ramtop

  4. CQRS: When and Why Not good for Very Good for ✗ Read only aggregations (e.g. Reports) ✔ Complex mutable state ✗ Stateless calculations (e.g. risk) ✔ Separation of logic ✗ Very High performance (e.g. exchange) ✔ Auditing required ✗ Trivial CRUD (e.g. TODO lists) ✔ Orders, Trades, Editors @Ramtop @Ramtop

  5. Implementation Gradient Command Pattern Event Source CQRS Monolith CQRS Microservices @Ramtop @Ramtop

  6. Command pattern ✔ Allow replay to recreate State ✔ Separation of logic from infrastructure ✗ No automatic persistence ✗ Limited Scalability @Ramtop @Ramtop

  7. Event Source ✔ Allow replay ✔ Separation of logic ✔ Automatic persistence ✗ Limited Scalability @Ramtop @Ramtop

  8. Separation of Query Model ✔ Allow replay ✔ Separation of logic ✔ Automatic persistence ✔ High Scalability ✗ Complexity @Ramtop @Ramtop

  9. Split to Microservices @Ramtop @Ramtop

  10. Domain Driven Design @Ramtop @Ramtop

  11. Domain Driven Design DDD is a creative collaboration between technical and domain experts. Domain language must be reflected in the code. Code must let the business intention show up @Ramtop @Ramtop

  12. Functional Programming Immut mutab abili lity Pur urity Hi Higher order fun unct ctions ns No exceptions Trans ansformat mations s whi which h prese serse se properties @Ramtop @Ramtop

  13. There is no silver bullet but... DDD D + Even ent t Sourci Sourcing + Fun uncti tion onal al St Style @Ramtop @Ramtop

  14. @Ramtop @Ramtop

  15. Protagonists @Ramtop @Ramtop

  16. What is a ADT? Represent entities that can change state in an immutable world. An algebraic data type is a kind of composite type, i.e. a type formed by combining other types. Wikipedia @Ramtop @Ramtop

  17. What is a Fold? Specialized type of recursion In functional programming, fold refers to a family of higher- order functions that through use of a given combining operation, recombine the results of recursively processing its constituent parts, building up a return value. Wikipedia @Ramtop @Ramtop

  18. Commands A Command is a request for changing the internal state of the system A Command can “fail” if is not congruent with the current state of the System Each Command is executed in an atomic context @Ramtop @Ramtop

  19. Events Events are the “atoms” of System state change Nothing can change without an event, every event can change only one transactional aggregate State + Event => State @Ramtop @Ramtop

  20. Values and Entities They represent the state of the domain Values have no identity, Entities are distinct They are all immutables To keep state changes we have Algebraic Data Types @Ramtop @Ramtop

  21. Transactional Aggregates An aggregate is an aggregation of Entities They are composed by Entities and Values It has all the information for a transaction unit Aggregates is what Events fold to @Ramtop @Ramtop

  22. Queries A query ask for a snapshot of the state Queries typically need different data and denormalization from domain model. So we separate the models in CQRS. Queries are only eventually consistent with the domain @Ramtop @Ramtop

  23. Actors More powerful and easy to use concurrency model than Threads/Locks They communicate asynchronously and potentially remotely Useful for Bounded Contexts and Services Remote Actors works like Microservices @Ramtop @Ramtop

  24. Event Store Store tuples (timestamp, type, uuid, event, version) Query by index fast Dynamic query In memory implementation can be enough @Ramtop @Ramtop

  25. github.com/uberto/anticapizzeria @Ramtop @Ramtop

  26. Antica Pizzeria ● Real application is about finance products booking but a pizzeria has a surprising similar domain ● We want to do implement the backend for a ChatBot that will assist booking and enquires about orders. @Ramtop @Ramtop

  27. Events Tree @Ramtop @Ramtop

  28. Commands @Ramtop @Ramtop

  29. Events @Ramtop @Ramtop

  30. Queries @Ramtop @Ramtop

  31. Queries listen to Events (t (to k keep ep u up wi with th the chan the changes ges) @Ramtop @Ramtop

  32. Let's fold Events (t (to cr creat ate E Ent ntiti ties es) @Ramtop @Ramtop

  33. Entities as EventComposable @Ramtop @Ramtop

  34. Commands emit Events @Ramtop @Ramtop

  35. Logic is called by Commands @Ramtop @Ramtop

  36. Actors (whe (where we e we can p can put al all thi this stu tuff) @Ramtop @Ramtop

  37. Application @Ramtop @Ramtop

  38. Tests can process C&Q @Ramtop @Ramtop

  39. Add a new State to represent Dispatch when a pizza left the shop. Keep track of delivery person. @Ramtop @Ramtop

  40. Live Code @Ramtop @Ramtop

  41. Will you consider Event Sourcing in the future? @Ramtop @Ramtop

  42. QA Uberto Barbini @Ramtop github.com/uberto/anticapizzeria @Ramtop @Ramtop

  43. @Ramtop @Ramtop

Recommend


More recommend