How grainy should a domain event be?

Question

I wonder how grainy a domain event should be?

For example, I have something simple, like changing the firstName name, second name and email address on the profile page. Should I have 3 different domain events or only one?

In case of rough grainy domain events, when I add a new function, I need to create a new version of the event, so I need to add a new type of event or save the version of events in the event store. With fine-grained domain events, I don't have these problems, but I have too many small classes. What do you think is the best practice in this case?

Answer 1

What is the problem with many classes? Indeed, why are so many developers afraid to have too many classes? You define as many classes as necessary.

A domain event signals that the domain has changed in a certain way. It should contain all relevant information, and the fact that the event is also a DTO should be considered. You need clear events, but the developer must decide how granular or overall the event is.

Size is not a concern, but if your event weighs 1 MB, you may have a problem. And the number of classes is not a design criterion for domain events.

Answer 2

I can agree with MikeSW's answer, but by applying SRP during simulation, you can end up with small classes, which is not a problem at all.

According to Greg Young , domain events should always express what the user is doing from a business perspective. For example, if a user has 2 reasons to change his PhoneNumberChanged phone PhoneNumberChanged , and this information can be important from a business point of view, then we must create 2 types of events PhoneNumberMigrated , PhoneNumberCorrected , to technically save the same data. This clearly violates DRY, but this is not a problem, because SRP can redefine DRY in cases such as this by sharing aggregates and their properties (most often a common identifier) ​​between several limited contexts.

In my example:

I have something simple like changing firstName, secondName and email address on the profile page.

We must ask the following: why does the user need this, does it have any meaning from the point of view of our business?

• her account was stolen (security, not a business problem)
• she switched to another email address
• she got married
• she hated her previous name
• she gave a report to someone else
• etc...

Well, if we have the services of a dating agency, then registering a divorce can probably be of business value. Therefore, if this information is really important, we must put it in the domain model and create the UserProbablyDivorced event. If none of them is important, we can simply say that she just wanted to change her profile page, we don’t care why, so I think that in this case UserProfileChanged or UserSecondNameChanged events may be acceptable.

Domain events can be in a 1: 1 ratio and in a 1: n ratio with teams. The 1: 1 ratio they call is usually the same as in the teams, but in the past tense. For example ChangeUserProfile -> UserProfileChanged . At a 1: n ratio, we usually share the behavior that the team represents in a series of smaller domain events.

So, to summarize, this is the decision of the domain developer how granular the events of the domain are, but it should clearly affect the business perspective, and not just the modeling perspective of the data schema. But I think this is obvious because we are modeling a business, not just a data structure.