When to update validation fields? DDD

Question

I have a collection object:

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

and a

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

The meeting, as the Aggregated Root, has an AssignEmployee method.

I was about to transfer the current user to the Meeting object when I call AssignEmployee so that it can update its audit fields accordingly.

But that doesn't seem right - does it? Obviously, I can publish audit fields and change them later - perhaps at the service level?

What is another preferred method for updating these fields?

Please note: we do not use Nhibernate, but a custom ORM that has nothing automatic in place.

Thanks.

Answer 1

Auditing and logging is fun, as they are usually needed throughout the application, and both are requirements (logging is a requirement from OP pairs).

Without knowing most of your model, and since auditing should be a requirement, I have to pass the current user to AssignEmployee , and instead of the line where AuditBlahBlahBlah indicated, I would add an event (maybe MeetingUpdated or AssigneeAdded ... you will find a good name), and this event is dispatched to the class that performs the audit. Thus, the Meeting class has no idea about checking and sending business events for audit purposes (which, in my opinion, is very DDDish).

I wonder what other people can say (I hope I can learn something new!)

Answer 2

Consider using domain events.

Anything interesting in your domain model should trigger an event screaming out loud for what just happened. Outside, just attach a log handler that uploads them to db or somewhere else.

This way you do not need to spoil your domain in any way IAuditService.

Even better, the domain model can use eventing as a way to communicate within itself.
To show why this is a good idea, visualize that we are describing a domain model of morning, sunrise, and flowers.

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

Another analogy is the responsibility of the driver for what color of the traffic light.

Answer 3

You can call the audit service from the service level when saving or updating objects, while the audit service will be implemented in any services that require audit functions, and the newly created objects will be saved as soon as possible.

I see how difficult it would be to determine how and when to conduct an audit, especially if your entities exist as used entities in the system before they are saved. Even if they exist for some time before they are saved, you can probably create audit data in memory containing the details of their creation, and then save it when the entities are eventually saved. Or whether the data of the created, created, modified, changed, etc. is set. How are private fields in essence written to the audit log when an object is saved?

I would be interested in what compromises will be.