When to update audit fields? DDD

Question

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.

Answer 1

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!)

Answer 2

Consider using domain events.

Everything interesting in your domain model should raise an event shouting aloud of what just have happened. From outside, just attach log handler that dumps them in db or somewhere else.

That way - you don`t need to mess up your domain with some kind of IAuditService's.

Even better - domain model can use eventing as a way to communicate inside of itself.
To show why that`s a good idea - visualize that we are describing domain model of morning, sunrise and flowers.

Is it responsibility of sun to tell all the flowers that they should open? Not really. Sun just needs to shine brightly enough (to raise an event), light must travel down to earth (there must be some kind of infrastructure that makes eventing possible) and flowers must react themselves when receiving light (other domain models should handle events).

Another analogy - it's responsibility of driver to see what's the color of traffic lights.

Answer 3

You could possibly make the call to the audit service from the service layer when persisting or updating the entities, with the audit service having being injected into any services that require audit functionality, and persist the newly created entities as quickly as possible.

I see how it could be hard to work out how-and-when to audit, especially if your entities are going to exist as usable entities in the system sometime before being persisted. Even if they exist for some time before being persisted, maybe you could create in-memory audit data, containing the details of their creation and then persist that when the entities are eventually persisted. Or have the created-by, created-on, modified-by, modified-on, etc. data set as private fields in the entity and write it out to an audit log when the entity is persisted?

I'd be interested in what the trade-offs would be.

Answer 4

I think that the auditing properties are not a concern of your domain model. If all the use cases available in your application services layer use the domain model to make changes in the system, and the aggregate roots publish anything that has happened as Domain Events later on you can implement a handler for any event and it saves them in the audit log format you need.