![image](https://private-user-images.githubusercontent.com/1863005/325228611-d4b0aab3-67df-45d8-8845-809044fd5e66.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjE3NDU4MTQsIm5iZiI6MTcyMTc0NTUxNCwicGF0aCI6Ii8xODYzMDA1LzMyNTIyODYxMS1kNGIwYWFiMy02N2RmLTQ1ZDgtODg0NS04MDkwNDRmZDVlNjYucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDcyMyUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA3MjNUMTQzODM0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NDYwNzNhN2EyMTNiMWI5NjQ1MGY5MzkzNTYyZDYxZTIyMzM3NjlhMjA2MzVhZmRkODcwYjk3YTBjNWQ4ZTA1ZiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.ktIDX1DnE3hxzXfQ4R5WAVLiPhta0SqCDua-tk7j7p8)
- Storing only "current state" completely loses all business value of "how things got this way over time" (time traveling lost)
- Think about showing how event-sourced projections do the same level of work that is traditionally done by complicated SQL queries and graph building from disparate data sources -- but when combined with read-models they do them ahead of query time so as to optimize the retrieval of such data when it's used.
- Different thinking
- Requires training
- Immutability forces complication here
- Greg Young wrote "Versioning in an Event Sourced System" boook on the subject
- Introduces "moving parts" -- covered in CQRS chapter
Beware of these when deciding whether or not to use an event-sourced domain model. Simpler, "current state" based approaches may be sufficient in many scenarios. Chapter 10 gives rules of thumb.
- Make sure to benchmark actual vs feared impact
- Consider aggregate lifespan and number of events within this window
- Fewer than 10k events is usually not a problem
- Snapshot pattern can be introduced to mitigate
- Cached representations of the aggregate's current state up to recent time period.
- Note that this is how EventStoreDB works with projections (TODO: Link to CommitStream examples)
- Easy to shard all events for aggregates to specific nodes / stores
- Apply forgettable payload pattern
- Encrypt sensitive data with customer-specific key
- Delete key when customer requests or other occurence dictates
- Error prone
- Two-stage transaction, subject to rollback, partial failure
- Prone to engineer forgetting to apply consistency
- Log table schema usually degrades into chaos
- Only includes dry facts
- No capture of business intent or user intent at all
- No ability for really projecting alternate reports of read models via "time travel"
- Event-sourced domain model adds dimension of Time
- All aggregate changes expressed as domain events
- As opposed to simply changing a database row or document's "currentn state"
- This gives ability to "time travel" for alternate reports and read models
- Gives deep insight ability
- A
- C
- B -- B & C
- A