Reputation: 37
For example, I have the following code:
public void Update(string firstName,
string? middleName,
string lastName,
string emailAddress,
string phoneNumber,
DateTime birthDate,
Gender gender,
string comment,
string? avatarUrl = null)
{
SetFullName(firstName, lastName, middleName);
SetEmail(emailAddress);
SetPhoneNumber(phoneNumber);
SetBirthDate(birthDate);
SetGender(gender);
if (avatarUrl is not null)
{
SetAvatarUrl(avatarUrl);
}
SetComment(comment);
AddPersonUpdatedDomainEvent();
}
At the end of the update, I add a domain event for the update, but anyone can call methods like SetFullName
, SetEmail
, SetPhoneNumber
separately, so I would need to handle domain events there as well. However, this creates a problem because calling one complete update results in 8 domain events being added, which doesn't seem right. Ultimately, I only need to handle one "update" event.
Is it acceptable to remove/update previously added update events if they already exist?
Upvotes: 0
Views: 54
Reputation: 57397
Is it acceptable to remove/update previously added update events if they already exist?
In the common case, the usual answer is "no" - events are little data structures / messages that we use to keep track of what has happened, and you can't "un-happen" an event, so deleting your record of what happened isn't a particularly good idea.
This is especially the case when the information propagates through the system; other parts of your system are also reacting to the information in the event and changing. Deleting messages really messes with your ability to reconstruct what happened and why.
What you are more likely to see are "reversals" - creating an event that undoes the effects of an earlier event. The reversal metaphor comes from accounting? where you have an error remediation protocol based on creating additional entries in the ledger.
this creates a problem because calling one complete update results in 8 domain events being added, which doesn't seem right
The common examples reverse the arrangement of modifications and events from what you show here. Which is to say, the method in your domain object that mutates its state is usually written using a structure like
public void Update(...)
// compute a data structure that describes the changes
// that will be made to the state of the domain entity
val event = new UpdateEvent(...)
// change the state of this local entity
this.apply(event)
}
See Greg Young's m-r domain model, as an early reference to this approach.
So in practice you would create a small number of events (usually 1) per use case / transaction, and then apply those events to update the data structure.
It's probably worth noting that domain models that are "just" storing information provided by the outside world have a different set of trade offs than those that manage information "owned" by the domain model itself.
For something like a UserProfile, where you are caching information passed to you via some form submission, and if we want to distinguish changes that correct earlier data entry errors (you have the wrong spelling of my name) from life events (my name has officially been changed), then that would usually be realized using different form submissions, and the form submissions would have different handlers (See also Greg's essay on task-based ui).
Upvotes: 1
Reputation: 45
There are multiple ways to achieve this:
My preference is to have more granular events for more control and I will probably not fire the general "AddPersonUpdatedDomainEvent" event, but as I say that may vary from application to application.
In summary I think there is strict rules how to do this, but it may depend of application needs.
Upvotes: 1