Downloaded 10 times
![Breaking changes
removing attribute
leave it in
renaming of attribute
add new attribute or live with it
changes of semantic meaning
e.g. discount of price in percentage or euro?
type changes
e.g. flag to array
better to add an additional array to the existing flag
event {
"id": 123
”discont": ”10”
"flag": "boolean”
”newFlag": ["boolean”]
}](https://image.slidesharecdn.com/dddcqrseventsourcingpublished-180224124952/75/DDD-meets-CQRS-and-event-sourcing-34-2048.jpg)
![“
”
[...] each pattern represents our current best
guess as to what arrangement of the physical
environment will work to solve the problem
presented.
[...] patterns are still hypotheses, all 253 of
them—and are therefore all tentative, all free to
evolve under the impact of new experience and
observation.
— Christopher Alexander et al., A Pattern Language, p. xv, 1977
conclusion
• apply the patterns wisely, you don’t have to use (all of)
them!
• patterns change over time! new patterns emerge
permanently!](https://image.slidesharecdn.com/dddcqrseventsourcingpublished-180224124952/75/DDD-meets-CQRS-and-event-sourcing-48-2048.jpg)
![[MongoDB.local Bengaluru 2018] Introduction to MongoDB Stitch](https://cdn.slidesharecdn.com/ss_thumbnails/1420-introductiontomongodbstitch-nishant-bengaluru-180425154744-thumbnail.jpg?width=640&height=640&fit=bounds)
![[MongoDB.local Bengaluru 2018] Keynote](https://cdn.slidesharecdn.com/ss_thumbnails/keynote-mongodb-180425154328-thumbnail.jpg?width=640&height=640&fit=bounds)
![[MongoDB.local Bengaluru 2018] Just in Time Validation with JSON Schema](https://cdn.slidesharecdn.com/ss_thumbnails/1240-justintimeschemavalidationdinesh-180425155701-thumbnail.jpg?width=640&height=640&fit=bounds)
DDD meets CQRS and event sourcing
- 1. ddd meets cqrs and eventssourcing
- 2. who am I gottfriedszing doing IT stuff for 30+ years requirements engineer/business analyst software/solution architect java, kotlin, js @GottfriedSzing gottfried@szing.eu
- 3. what to expect... some patterns & concepts no code, json snippets for illustration no silver bullet for solving problems a possible path to an scalable, maintainable, fault tolerant, fault resilient application
- 4. Patterns & Conceptsin DDD
- 5. Patterns & conceptsin DDD ubiquitous language domain & subdomain bounded context context map layered architecture entity value object aggregate service repository factory domain event
- 6. “ ” The essence ofa Domain Event is that you use it to capture things that can trigger a change to the state of the application you are developing. Martin Fowler, 2005
- 7. “ ” A Domain Eventis a record of some business-significant occurrence in a Bounded Context. Vernon, Vaughn. Domain-Driven Design Distilled, 2016
- 8.
- 9.
- 10. Characteristics of DomainEvents result of a state change events happened in the past events are facts events can never be rejected events can never be changed, they are immutable part of the ubiquitous language nameChanged invoicePrinted orderConfirmed callRecorded softwareCrashed
- 11.
- 12.
- 13. Slaying a monolith Microservicesto the rescue!?
- 14. What are microservices? Small, independent applications, loosely coupled, communicating with each other in an asynchronous manner (across system boundaries), and can fail independently, and if one or some fails, the system as a whole still works, though the functionality might be downgraded when there are failures.
- 15.
- 16.
- 17. Let’s try itagain...
- 18. CQS: command-query separation pattern on component level Methods either query or command but never both: query does not change state command does not return value, only changes the state read/write can have a separated model reads can be run multiple times without side effects reads are automatically idempotent
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25. CQRS for multipleread models
- 26. Example for commands& events commands for the write side: cause a state change of an aggregate public class ConfirmOrder { public Guid OrderId; } events for the result side: are the result of a command public class OrderConfirmed { public Guid OrderId; public DateTime ConfirmationDate; }
- 27. Properties of DomainEvents Name of event Noun + verb in past tense (+ "namespace”) at.bounded.context.callRecorded vs. callRecorded Timestamp when occurred Cause for change causation ID, reference to the command Granularity Enriched: all data inside; high coupling, internals Query-Back: only IDs; additional load, replay Empty: event itself is important
- 28. Concurrency of commands commandsshould be handled concurrently... ... but this could lead to conflicts!
- 29. Conflicts with command person{ "userId": 123456 "username": “root” } changeUsernameCommand { "userId": 123456 "username": "toor" } changeUsernameCommand { "userId": 123456 "username": ”admin" } usernameChangedEvent { "userId": 123456 "username": ??? }
- 30. Conflict resolution/prevention optimisticlocking first one wins last one wins pessimistic locking serialization of commands single-writer principle versioning of the aggregate
- 31.
- 32. Reason for changes aggregate boundaries are wrong new attributes refactoring typos type changes ...
- 33. Non-breaking changes addingattribute: up-casting of old events to new ones by using a new default by converting old events to new leads to cascades of up-casts and costs performance assumes an tolerant consumer event { "id": 123 } event { "id": 123 "state": "cool" }
- 34. Breaking changes removingattribute leave it in renaming of attribute add new attribute or live with it changes of semantic meaning e.g. discount of price in percentage or euro? type changes e.g. flag to array better to add an additional array to the existing flag event { "id": 123 ”discont": ”10” "flag": "boolean” ”newFlag": ["boolean”] }
- 35. Event sourcing What isevent sourcing?
- 37.
- 38. Persistence id name created_at 33Vernons Blog NOVEMBER 1, 2008 id blog title created_at posted content 12 33 Summary of CRDTs MARCH 01, 2015 MARCH 26, 2015 In this article I am going to introduce you to CRDTs....
- 39. Events for persistence Time blogEntryCreated12;33;MARCH 01, 2015 blogEntryEdited 12;“...CDRTs...” blogEntryEdited 12;“...CRDTs...” blogEntryPublished 12;Vernon, MARCH 25, 2015 blogEntryTitleChanged 12;“Summary of CRDTs” blogEntryEdited 12;“Yeah, But…” blogEntryPublished 12;Vernon, MARCH 26, 2015 blogEntryCreated 13;33;MAY 14, 2015 id blog title created_at posted content 12 33 Summary of CRDTs MARCH 01, 2015 MARCH 26, 2015 ...CRDTs... 13 33 MAY 14, 2015
- 40. Event sourcing eventsare the source of truth audit logging traceability easy temporal queries ability to put the system in prior state for debugging recreating state with new business logic replay of events bug fixing evolutionary architectures
- 41.
- 42.
- 43.
- 44. Events sourcing &integration blogEntryCreated Time blogEntryEdited blogEntryEdited blogEntryPublished blogEntryTitleChanged blogEntryEdited blogEntryPublished postPublished postPublished internal / private external / public
- 45.
- 46. Recap... domain events monoliths microservice distributed monoliths CQS CQRS CQRS with integration events event sourcing
- 47. Further topics andpitfalls versioning of events performance in event sourcing long running processes: orchestration vs. choreography sagas for long lived/distributed transactions how to identify domain events data protection, authorization, GDPR,... “reactive” microservices ...
- 48. “ ” [...] each patternrepresents our current best guess as to what arrangement of the physical environment will work to solve the problem presented. [...] patterns are still hypotheses, all 253 of them—and are therefore all tentative, all free to evolve under the impact of new experience and observation. — Christopher Alexander et al., A Pattern Language, p. xv, 1977 conclusion • apply the patterns wisely, you don’t have to use (all of) them! • patterns change over time! new patterns emerge permanently!
- 49.
Editor's Notes
- #38 https://vaughnvernon.co/?p=1012