Event Sourcing - History in the making

Transcript

1. Event Sourcing History in the making
2. Benjamin Dulau Entrepreneur anonymation.com Co-founder thebigbrainscompany.com Web architect @benjamindulau
3. Event Sourcing
4. ❝ I want a list of all members that signed in at least four times between 1st January and 15th January 2014… and … I want to compare this to the same period range but in 2013. ❞ Business guy
5. ID username last_login 1 ehamill 2007-01-22 03:04:39 2 lherman 2012-04-27 10:38:28 3 darien13 2010-06-16 21:43:06 4 olind 2012-01-02 04:31:21 … … … Current data
6. Event Sourcing resolves this issue.
7. RDBMS as the center of the architecture
8. State A Something
 important
 happened (delta) State B Time
9. State A Something
 important
 happened
 (delta) State B Dropped Stored Dropped Working with current state Time
10. Lost data could have a massive value for the business.
11. ID CartId SKU Qty 1 1 ABC 5 2 1 DEF 1 3 1 IJK 10 Cart Cart lines ID CustomerId 1 1 2 1 3 1 1 0..*
12. In life, the only way to understand the present is to look at the past.
13. If we know the events of the past, we can reconstitute the present.
14. Event Sourcing
15. State A Something
 important
 happened
 (delta) State B Stored Reconstituted Reconstituted Time Working with Event Sourcing
16. We express what happened
 in the past as a series of
 Domain Events
17. happened in the past.
18. CustomerWithdrewCash
19. A Domain Event is a Message emitted by the Domain Model to inform the system that something relevant happened.
20. class CustomerWithdrewCash implements DomainEvent { public $customerId; public $accountId; public $amount; public $date; public function __construct($customerId, $accountId, $amount, $date) { $this->customerId = $customerId; $this->accountId = $accountId; $this->amount = $amount; $this->date = $date; } }
21. A message has no behavior and it is easy to serialize.
22. Event Store
23. An append-only database storing a series of events organized in event streams.
24. Bob’s account stream (Domain Model) CustomerWithdrewCash CustomerDepositedMoney CustomerWithdrewCash CustomerPaidWithHisCreditCard
25. JSON JSON JSON JSON Bob’s account stream (Database - Event Store)
26. { payload: { customerId: "123", accountId: "456", amount: 150, date: "2005-08-15T15:52:01+00:00" }, eventType: "CustomerWithdrewCash" }
27. CustomerWithdrewCash CustomerDepositedMoney CustomerWithdrewCash CustomerPaidWithHisCreditCard Replay history Bob’s account current state balance.
28. Reconstituting JSON JSON JSON JSON Fetch & unserialize Domain Event Domain Event Domain Event Domain Event Domain Model Aggregate apply
 one-by-one Event stream Domain events object collection
29. No need for an ORM
30. Modelling freedom
31. No delete What’s done is done.
32. A delete is explicitly expressed as a domain event. It is part of history.
33. Immutability = Infinite caching
34. Transactional by nature
35. Business Intelligence
36. Allows to ask almost any question to the data.
37. Projections
38. Derivative of the facts
39. Code that goes over a stream of events and produces a transient state of it.
40. Domain Events UI View Models Statistics Models Search index Models API Read models
41. class LatestMemberViewGenerator implements EventHandler { private $memberDAO; public function __construct(MemberDAO $memberDAO) { $this->memberDAO = $memberDAO; } public function whenMemberHasSignedUp(MemberHasSignedUp $event) { $this->memberDAO->addToLatestMemberList(new LatestMemberItem( $event->memberId, $event->name, $event->username, $event->email, $event->date )); } }
42. Any structural representation of the data.
43. CQRS
44. Command Query Responsibility Segregation
46. Summary
47. Working with current state always involves valuable data loss.
48. Events in the domain should be explicitly expressed in the domain model and in the ubiquitous language.
49. Being able to replay history is a major benefit both technically and for the business.
50. Immutability is a bless.
51. A single model doing everything can’t be right and it won’t scale.
52. Questions?