Using a service bus implementation. When an email is read by a particular user we raise an event that the email has been read. We have a subscriber that then picks up on this event when it is raised. When the email is read we want to perform an action and then log that the email has been read in a database.
My question is:- Would you a) Raise another event which would then be subscribed to by a logging service which would listen to all logging events raised for this and other systems? b) Have the subscriber listening for the email read event log that the email had been read? c) Do something else?
Are you following DDD principles, if so, why would you want to have a service just to log?
If that "logging" is part of the requirements for the business, which would mean a state change in your repository, then it needs to be part of the transaction that raises the event raised after the user has read the email, not the other way round, but it seems to me that in a DDD point of view having a separate service just to log is not the best approach, also if you have a central service that handles all the messages in your system what would the point be in having a distributed system in the first place?
"Would you a) Raise another event which would then be subscribed to by a logging service which would listen to all logging events raised for this and other systems?"
I don't think you should do it, because an event handler should not publish another event it should instead submit a command.
On the other side, why can't you just have that log done, in the service that raises the event? because that is where the action is happening.
Marco