Modifying damage

[jaduff]

Unlike everything else in this program, Damage can be modified. The DamageDescription can be edited by the admin. Damage can be resolved through the bool DamageResolved. A ticket number can be added.

Should the event which creates the Damage also be the same event which modifies it? (with additional event constructors to match the DamageId which doesn't exist before the first creation event)

Should each piece of data being modified be a separate event, or a single event with different constructors depending on what is being modified?

Current DamageAddedEvent without ability to modify is shown below.

public class DamageAddedEvent : IEventBody
    {
        public DamageAddedEvent(string roomName, string serialNumber, int damageId, string damageDescription)
        {
            SerialNumber = serialNumber;
            DamageDescription = damageDescription;
            DamageId = damageId;
        }

        [Obsolete("This constructor is for serialization only. Do not use in code.")]
        public DamageAddedEvent()
        {

        }
        public string EventType => EventTypeString;
        public string DamageDescription {get; set;}
        public int DamageId {get; set;}
        public string SerialNumber {get; set;}
        public const string EventTypeString ="DamageAdded";
        public DateTime TimeAssigned {get;} = DateTime.Now;
    }

Essentially the question becomes:

1. Should events be as specific and granular as possible? (create vs modify vs delete)
2. What impact would a generalised event have on replaying events? Would need to check the DamageId in the Read Model to see if it already exists before adding an event, because you wouldn't know if it was a new or modified event.
3. In answer to 2. Would it be advisable to have a single event, which has multiple EventTypeStrings depending on the function?

[simonjduff]

Damage create and damage modify are definitely different events. Think about trying to read and understand an audit trail without being able to tell the difference. The events should be as granular as your domain dictates. We created a domain model early somewhere didn't we?

[jaduff]

Yes I’ve got a domain model. A damage modify event can modify a number of different properties (description, resolved, and ticket number). Should each of these be a different event for audit following purposes? Or just a single event? Presumably the latter, otherwise there could be a huge number of events.

[simonjduff]

Well, what methods do you have on your aggregate root to perform the modification? Do you have a "ModifyDamageDescription" method? Or just an "UpdateDamage" method?

[jaduff]

Neither yet, I'm trying to work out how its going to work first. I figured having an UpdateDamage method (and corresponding event) would reduce the number of events, and amount of repeated code required.

[jaduff]

So which would be the best practice approach? Individual events (and possibly methods) for each property to be updated, or a single update event?

[simonjduff]

A single event capturing the purpose of the update.

On Fri, 19 Jan 2018, 04:00 James Duff, notifications@github.com wrote:

So which would be the best practice approach? Individual events (and possibly methods) for each property to be updated, or a single update event?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/jaduff/LabLog/issues/45#issuecomment-358860550, or mute the thread https://github.com/notifications/unsubscribe-auth/ALHMqHdsU6S2Ygq8X0lwBURlAEQrPXpFks5tMBNHgaJpZM4Rgv-J .

[jaduff]

Need to change damage edit to new event type, instead of reusing create damage

[jaduff]

So if I've got two events that are essentially the same, except for the name, and that one generates a guid while the other receives it as an argument, how should I structure the inheritance between them to minimize repetition? Should the edit event inherit from the create event, or should both inherit from a common event?

[simonjduff]

Almost definitely neither. There should be very little commonality between the two events.

[jaduff]

As it turns out, the two events would be identical, because the damageId is created outside of the event creation. So they would be two exact duplicates, with the exception of the event name. Is this a meaningful approach? More code to maintain and update, for the purposes of human readability? What if there were one event called DamageEvent, which had a property indicating whether it was a create or an update?

[simonjduff]

Doesn't sound right to me, but you can always try it and see if it becomes annoying later on :P

[jaduff]

Given the create and update events are inextricably linked, and will always contain the same data, what is the downside that is so problematic that maintaining a duplicate event is worth the hassle?

[jaduff]

public string EventType => EventTypeString; public const string EventTypeString ="DamageAdded";

What would be the issue with having two possible EventTypeStrings, which were assigned depending on whether the event was a modify or a create, and keeping the related events in a single class?

if (action == 'update')
{
EventTypeString = 'DamageUpdated';
}
else
{
EventTypeString = 'DamageCreated';
}

Or some such?

[simonjduff]

Code it and will have a look

On Fri, 31 Aug 2018, 10:40 James Duff, notifications@github.com wrote:

public string EventType => EventTypeString; public const string EventTypeString ="DamageAdded";

What would be the issue with having two possible EventTypeStrings, which were assigned depending on whether the event was a modify or a create, and keeping the related events in a single class?

if (action == 'update') { EventTypeString = 'DamageUpdated'; } else { EventTypeString = 'DamageCreated'; }

Or some such?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/jaduff/LabLog/issues/45#issuecomment-417611469, or mute the thread https://github.com/notifications/unsubscribe-auth/ALHMqJCA9m3_zYZDspnfiP1KILDx8URPks5uWQShgaJpZM4Rgv-J .