Recomendados
Mais conteúdo relacionado
Último
Último (20)
Destaque
Destaque (20)
CQRS for human beings
- 4. 🔑 🔑
- 6. 🔑 🔑
- 8. 🔑 🔑 🔑 🔑
- 16. • • • •
- 17. • • •
- 19. •State: NotRunning •Title: “” •StartDate: null •SignedCount: 0 •Singers: [] •FinishDate: null PetitionStarted •State: Running •Title: “My new petition” •StartDate: 08/05/2018 SignerAdded •Singers: [“Todor Todorov”] SignerCountChanged •SignedCount: 1 PetitionFinished •State: Finished •Title: “My new petition” •StartDate: 08/05/2018 •SignedCount: 1 •Singers: [“Todor Todorov”] •FinishDate: 09/05/2018
- 21. • • • •
- 25. • • • •
- 26. • • • • • •
Notas do Editor
- Introduce yourself 1 year with CQRS and Event Sourcing Passion about CQRS I will guide you through the evolution of our software. Because to me, CQRS is the natural evolution step in enterprise software development.
- Ask questions you might forget Give feedback Vote in the poll Get the presentation
- Document management system – Monolith Client wanted a workflow engine Execute business processes over documents Storing a document triggers a workflow (INSTANCES) Indexing is applied Users get tasks Users confirm decisions Workflow ends Q: How many monoliths here?
- A trivial CRUD system Instances are created Tasks deleted after confirmation Instances are deleted after finish Small DB = Fast requests Client wanted History Missing History We could do one thing
- Great developers Did it by the books PO had to think of this
- Stop deleting anything Add state column Get History from here Client wants History of automatic steps Missing
- 1. PO is to blame again
- Added History tables Move from active to History Data = Text for UI Customer got a corrupted workflow. Asked to restore it from history Can’t, history is only for UI
- Getting in the cloud GetTasks – SLOW MANY LOCKS History – UNUPGRADEABLE Scaling – Not very efficient Q: Anyone had such problems? Q: How did you solve it?
- Colleague said CQRS is awesome Skeptic at first Many discussions Changing architecture is hard But first – WHAT IS CQRS? It is not scary!
- OK, it is scary! That makes you cringe Let’s simplify
- Not so scary now Makes sense WHY do we need that? Did a research We read more than we write
- Our logs show that Q: Have you done such a check? Q: What does it show? 11 TIMES MORE
- Started thinking about separation How do you separate your model? Makes a lot of sense Many things – not used in both Colleague afraid to have much data in table Told him because he haven’t split
- Read site (query model) Queries return data Write side (command model) Commands mutate state Separated Async – Not mandatory But preferable
- Scale Read & Write independently Read side denormalized Read side straightforward Write side is not UI dependent Model separation is meaningful Scales better
- CAP Theorem Eric Brewer 1998 You need to duplicate data in models quite often
- State is stored as a series of events Append only store Compares to transactional log of DB Entities are called Aggregates
- Start by initial instance Apply events one by one Each event changes specific properties Idempotent events Applied events go to Projections (ReadModels) Auditing
- Concerned about size How to iterate millions of events
- If you use SQL – it is FAST Good PK = FAST EventStore NoSQL Snapshotting = aggregate state every 5-10 events Small DB footprint with Google Protobuf At time of choice – best serialization
- Made Get tasks faster Most important about client Confirms are async in the background How fast?
- Can you guess how much A LOT, PEOPLE!
- Independently scale Split models = clear models GetTasks got a lot faster Create Read Models Easy Auditing! Fancy words on our resume and site That was a joke… No it’s not (DO NOT READ)
- In my blog In Slido
- THANK YOU