Generic Events vs Specific Events

EventStoreDB
1

I am
new to event sourcing, and am looking at using it for a CRM system.

I was recently
debating with a fellow developer whether or not generic events or more specific
events are a good idea.

We are both novices at ES, so it was the blind talking to the blind. :slight_smile:

Here are the example commands and their events we are debating. Our model is a lead stream that has status and contact information.

Command #1 “CreateLead”

Events (Stored as a result of the command)
LeadCreated

LeadContactCreated

LeadContactSetToPrimary

LeadStatusChanged

Command #2 “ChangeStatus”

Events

LeadStatusChanged

Command #3 “SetPrimaryContact”

Events

LeadUpdate – Includes Updated Data

etc

Or this more generic approach.

Command #1 “CreateLead”

Events
LeadCreated – Includes all the lead data

Command #2 “ChangeStatus”

Events

LeadUpdate – Includes Status Data

Command #3 “SetPrimaryContact”

Events

LeadUpdate – Includes Updated Data

Here are my questions.

  • Is it a good practice to have multiple events per command? Or is it one to one with the command, CreateLead and LeadCreated
  • Are generic events a good idea? We felt we lose some fidelity. We were thinking would still store the command that was successfully run.

Hope this makes sense.

Thanks in advance,

Bryan

2

In my system I go more and more towards having a single model concept be a single event, so a command that gathers a lot of information could lead to multiple events, sometimes 10+ (like a user signup for example). When other commands can lead to same concept being updated it will use the same events, and so subscribers don’t have to understand new events all the time. Commands are specific to the use case, events are specific to the model. To tie it all together I include the command name as metadata, so that subscribers that care about why something changed can use that, especially for reporting (user status change due to signup vs status change due to admin commands)

3

So your domain dictates the event.

Would you go so far as , AgreggateUpdated which has the diff of what has changed, instead of specific events? Reason I ask, is how do you predict what people need from your domain? Why not a generic event, then let them see what was updated and figure it from the data being changed.

4

So your domain dictates the event.

Pretty much, yes.

Would you go so far as , AgreggateUpdated which has the diff of what has
changed, instead of specific events? Reason I ask, is how do you predict
what people need from your domain? Why not a generic event, then let them
see what was updated and figure it from the data being changed.

We don't have any external consumers, so we know exactly what we need
from our domain. In any case, since the storage/exchange format is
JSON, I'm not sure how an AggregateUpdated event would help. If I have
an implementation class with a hashmap (i.e. AggregateUpdated), or
event specific classes with fields, makes no difference (it's an
implementation detail for the publisher/subscriber), and so I prefer
specific classes for all the usual reasons classes are easier to use
than hashmaps.

Having a specific event name is absolutely crucial though, for
reporting purposes. Updating fields in a database, as the app itself
would do, is one thing. Being able to count how many times a specific
event has occurred in a day is another very very useful case.

/Rickard