Search code examples
domain-driven-designauditingaggregateroot

When to update audit fields? DDD


I have a Meeting Object:

Meeting{id, name, time, CreatedBy, UpdatedBy}

and a

MeetingAssignee{id, MeetingID, EmployeeId, CreatedBy, UpdatedBy)

Meeting, as Aggregate root, has a method AssignEmployee.

I was about to pass in the current user to the Meeting object as I call AssignEmployee, so that it can update its audit fields accordingly.

But this doesn't seem right - is it? Obviously I can keep the audit fields public and change them later - perhaps at service level?

What is everyone's else preferred method for updating these fields?

Please note: We are not using Nhibernate, but a custom ORM which does not have anything automatic in place.

Thanks.


Solution

  • Auditing and logging are fun as they are usually needed everywhere in the application and they are both requirements (logging is a requirement from the OPs guys).

    Without knowing much of your model, and since auditing must be a requirement, I would pass the current user to AssignEmployee and instead of having a line there that says AuditBlahBlahBlah, I would add an event (maybe MeetingUpdated or AssigneeAdded... you'll find a good name) and that event gets dispatched to the class that does the auditing. In this way the Meeting class has no clue about auditing and dispatches business events for auditing purposes (which, in my view, is very DDDish).

    I wonder what other people might say (hopefully, I can learn something new!)