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.

Contented

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

Antiparticle

I wondered about using the Event Aggregator or Event Sourcing patterns recently for this sort of thing. – Layard

I love events, they are so OO and go hand to hand with the concept of message sending, rather than 'method invocation' (which even sounds procedural) . By the way, I'm java developer and we don't have the luxury of having events as in .net :(, enjoy them! I would add: do most if not all of your logging and auditing using events - the book Growing Object-Oriented Systems, Guided by Tests has a very good example about this. – Antiparticle

Thanks I'll check that book out, the whole logging and auditing using events is something I hadn't really considered until recently. I'll have to do some reading on the subject. – Layard

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.

Pickaxe

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.

Layard

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.

Extramarital