There are no silver bullets in our profession. Not a single principle, practice, pattern or architecture style is applicable in all situations. But in 2013, I fell in love with Event Sourcing, an architectural approach coined by Greg Young. (cont'd)
Comments
Log in with your Bluesky account to leave a comment
I implemented a sub system of our whole application with ES and I absolutely love this approach, it seems like a natural fit for many scenarios; however, as you mentioned it’s no panacea and should not be treated as such.
✅ Do model your aggregates around invariants instead of business concepts or data-oriented models.
✅ Don’t be dogmatic about cross-aggregate transactions.
✅ Do assign a (natural) partition key to each aggregate to allow for easier scaling if needed. (cont'd)
✅ Do treat the event store as one big audit log of what happened in the business and never change or reorder events.
✅ Don’t treat events as a way to capture property changes.
✅ Don’t use domain events as a communication mechanism between domains or services. (cont'd)
✅ Don’t change the events just to optimize projection speed.
✅ Do be explicit about what information you want to keep in events based on functional requirements.
✅ Do give events unique identifiers and use them to associate projections with the latest event used. (cont'd)
✅ Do use autonomous asynchronous projections by default.
✅ Be careful: under load, queuing an SQL-based event store with a global checkpoint may cause you to miss events due to in-flight transactions. (cont'd)
✅ Treat rebuilding a projection as a special state: have the projector mark itself as rebuilding and expose progress as an ETA.
✅ Do whatever you can to make rebuilding fast.
✅ Don’t join data from multiple projections unless you’re sure it's safe. (cont'd)
Comments
✅ Don’t use Event Sourcing unless your domain needs to capture facts or decisions or has to deal with a high degree of user collaboration. (cont'd)
✅ Don’t be dogmatic about cross-aggregate transactions.
✅ Do assign a (natural) partition key to each aggregate to allow for easier scaling if needed. (cont'd)
✅ Don’t treat events as a way to capture property changes.
✅ Don’t use domain events as a communication mechanism between domains or services. (cont'd)
✅ Do be explicit about what information you want to keep in events based on functional requirements.
✅ Do give events unique identifiers and use them to associate projections with the latest event used. (cont'd)
✅ Be careful: under load, queuing an SQL-based event store with a global checkpoint may cause you to miss events due to in-flight transactions. (cont'd)
✅ Do whatever you can to make rebuilding fast.
✅ Don’t join data from multiple projections unless you’re sure it's safe. (cont'd)