Event Sourcing From the Trenches: Domain Events
See the original posting on DZone Python
While visiting QCon New York this year, I realized that a lot of the architectural problems that were discussed there, could benefit from the Event Sourcing architecture style. Since I’ve been in charge of architecting such a system for several years now, I started to reflect on the work we’ve done, e.g. what worked for us, what would I do differently next time, and what is it that I still haven’t made my mind up about. After having discussed aggregates in my last post, let me share some of my thoughts on domain events.
Avoid CRUD Terminology
Don’t use terms like create, update, and delete in the names of your events. Business doesn’t talk in those terms, so you should’nt either. Stick to the terminology from your Ubiquitous Language that applies to the involved bounded context. Again, Event Storming will help here as well since the names will surface during the discussion with business.