CQRS + Event sourcing

Achieving a 100% auditable application log with CQRS and Event sourcing

Transcript

1. CQRS and event sourcing Achieving a 100% auditable application
2. Who am I • Former standup-comedian • Software developer and dancer • Not a big fan of Jon Snow
3. Trafikkforsikringsforeningen function theirBusiness() { if(!yourCar.hasInsurance()) { val yourFine = createFine(yourCar.numberOfUninsuredDays()) allowComplaintsFor(yourFine)
 }
 }
4. Challenges
5. Challenges • We need to look at the current state to calculate fines
6. Challenges • We need to look at the current state to calculate fines • We also need to look at the whole history of the state to fully understand the fines
7. Challenges • We need to look at the current state to calculate fines • We also need to look at the whole history of the state to fully understand the fines • Customer also wants business analytics based on history
8. Goals for changes in the system
9. Goals for changes in the system • Who made the change
10. Goals for changes in the system • Who made the change • When did the change happen
11. Goals for changes in the system • Who made the change • When did the change happen • What was the previous change
12. Goals for changes in the system • Who made the change • When did the change happen • What was the previous change • Why did the change happen
13. CQRS
14. CQRS • Command Query Responsibility Segregation
15. CQRS • Command Query Responsibility Segregation • Simply put: separating your writes from your reads
16. Examples of commands data class KlagesakCreateCommand( override val principal: Principal, override val gebyrId: GebyrId, val principalRole: ActionRole, val klagesakId: KlagesakId, val reference: Long, val body: String, val attachments: List<AttachmentReference>, val email: String?, override val commandId: UUID = UUID.randomUUID() ) : • An intent to do something • Not guaranteed to succeed
17. ES
18. ES • Event Sourcing
19. ES • Event Sourcing • We store only the changes, not the state
20. Examples of events data: { "gebyrId": “gebyr:94668137", "principalRole": "ADMIN", "klagesakId": "37cf7d9c-3183-41f6-8094-b44d8a855528", "reference": 60078, "email": "example@example.com", "klageAarsak": null } meta: { “time”: “2019-05-15T08:44:21.382Z”, “principalId”: “selskapUser:0200:testtffadm” }
21. What does this enable?
22. The write model
23. Some domain concepts
24. Some domain concepts • 1 Kjøretøy can have multiple Gebyr
25. Some domain concepts • 1 Kjøretøy can have multiple Gebyr • 1 Gebyr can have multiple Klagesak
26. Some domain concepts • 1 Kjøretøy can have multiple Gebyr • 1 Gebyr can have multiple Klagesak • 1 Klagesak can have multiple Melding
27. Some domain concepts • 1 Kjøretøy can have multiple Gebyr • 1 Gebyr can have multiple Klagesak • 1 Klagesak can have multiple Melding • Melding
28. Some domain concepts • 1 Kjøretøy can have multiple Gebyr • 1 Gebyr can have multiple Klagesak • 1 Klagesak can have multiple Melding • Melding Aggregate Entity Entity Entity
29. Aggregate
30. Aggregate • Represents a transaction boundary (i.e. everything that is contained inside this boundary, does not care about what the rest of the world does)
31. Aggregate • Represents a transaction boundary (i.e. everything that is contained inside this boundary, does not care about what the rest of the world does) • The “root” of your data
32. Aggregate • Represents a transaction boundary (i.e. everything that is contained inside this boundary, does not care about what the rest of the world does) • The “root” of your data • Example: Your vehicle. All the fines related to your vehicle are contained inside this boundary and do not interact with fines on other vehicles.
33. Entity
34. Entity • Similar to an aggregate, but cannot exist on its own.
35. Entity • Similar to an aggregate, but cannot exist on its own. • Example: Every gebyr related to your vehicle is self- contained, but a gebyr cannot exist without a vehicle
36. The read model
37. Short demo (cross your fingers)
38. So why GraphQL?
39. So why GraphQL? • Fits well with CQRS: GraphQL mutations translate to commands and GraphQL queries translate to queries
40. So why GraphQL? • Fits well with CQRS: GraphQL mutations translate to commands and GraphQL queries translate to queries • Authentication
41. So why GraphQL? • Fits well with CQRS: GraphQL mutations translate to commands and GraphQL queries translate to queries • Authentication • Flexibility: multiple views share same endpoint while customising the data received
42. So why GraphQL? • Fits well with CQRS: GraphQL mutations translate to commands and GraphQL queries translate to queries • Authentication • Flexibility: multiple views share same endpoint while customising the data received • Direct mapping from domain objects to API responses
43. Write vs Read model
44. Write vs Read model Write model (aggregates)
45. Write vs Read model Write model (aggregates) • Unidirectional
46. Write vs Read model Write model (aggregates) • Unidirectional • Immutable
47. Write vs Read model Write model (aggregates) • Unidirectional • Immutable • Serializable
48. Write vs Read model Write model (aggregates) • Unidirectional • Immutable • Serializable • Versioned
49. Write vs Read model Write model (aggregates) • Unidirectional • Immutable • Serializable • Versioned • Highly cacheable
50. Write vs Read model Write model (aggregates) • Unidirectional • Immutable • Serializable • Versioned • Highly cacheable Read model
51. Write vs Read model Write model (aggregates) • Unidirectional • Immutable • Serializable • Versioned • Highly cacheable Read model • Bidirectional (forms a graph)
52. Write vs Read model Write model (aggregates) • Unidirectional • Immutable • Serializable • Versioned • Highly cacheable Read model • Bidirectional (forms a graph) • Non-serializable
53. Write vs Read model Write model (aggregates) • Unidirectional • Immutable • Serializable • Versioned • Highly cacheable Read model • Bidirectional (forms a graph) • Non-serializable • Context specific
54. Write vs Read model Write model (aggregates) • Unidirectional • Immutable • Serializable • Versioned • Highly cacheable Read model • Bidirectional (forms a graph) • Non-serializable • Context specific • Lazily evaluated
55. Lessons learnt
56. The good
57. The good • Incredibly easy to implement business analytics on existing data
58. The good • Incredibly easy to implement business analytics on existing data • Easy to formalise write rules for your data without relying on database triggers (and therefore not worrying about consistency across different database tables)
59. The good • Incredibly easy to implement business analytics on existing data • Easy to formalise write rules for your data without relying on database triggers (and therefore not worrying about consistency across different database tables) • Major performance gains possible
60. The good • Incredibly easy to implement business analytics on existing data • Easy to formalise write rules for your data without relying on database triggers (and therefore not worrying about consistency across different database tables) • Major performance gains possible • Not a single table join (okay, just a few here and there)
61. The good • Incredibly easy to implement business analytics on existing data • Easy to formalise write rules for your data without relying on database triggers (and therefore not worrying about consistency across different database tables) • Major performance gains possible • Not a single table join (okay, just a few here and there) • Authentication can be made super simple
62. The bad
63. The bad • Higher threshold to begin with
64. The bad • Higher threshold to begin with • Monkey-patching stuff in production is not so viable (still possible)
65. The bad • Higher threshold to begin with • Monkey-patching stuff in production is not so viable (still possible) • Complexity is much higher than in a regular CRUD system ⚠
66. The bad • Higher threshold to begin with • Monkey-patching stuff in production is not so viable (still possible) • Complexity is much higher than in a regular CRUD system ⚠ • Slightly niche way of doing this, which makes googling harder
67. Not covered in this talk
68. Not covered in this talk • How we achieved consistency across simultaneous writes
69. Not covered in this talk • How we achieved consistency across simultaneous writes • Projections (central to search capabilities)
70. Not covered in this talk • How we achieved consistency across simultaneous writes • Projections (central to search capabilities) • Details of authentication
71. Not covered in this talk • How we achieved consistency across simultaneous writes • Projections (central to search capabilities) • Details of authentication • Database structure (application is database agnostic)
72. Not covered in this talk • How we achieved consistency across simultaneous writes • Projections (central to search capabilities) • Details of authentication • Database structure (application is database agnostic) • Choice of language (it matters)
73. Recommended reading material
74. Q/A