Hi Clean Code Discussion board,
another question arose the other day while implementing a new feature on an already deployed and running system.
The request was to track all changes, the logged in user makes to the system. At a first glance I thought to myself: "Nice, we can let the gateways do this, without adding additional knowledge to the core system and its use cases."
That sounded reasonable and simple to me at first. But than it struck me. The log has to store not only what has changed, it also has to change who changed it, damn!
The next idea for a possible implementation was "Let's add it to the use cases which change the state of the entities. This feature is strongly correlated to the changing use cases, it should be in a central place of the system."
But this brought up another problem: Most of the use cases had no idea, "who" is currently using them. Since no changes to the system required any kind of a user context. All access control lays behind the log in wall of the delivery layer.
We did not want to add the current user information to every request object of the regarded use cases, so this second approach was also kind of "not implementable".
We came up with a specific logging use-case, which accepted the users identifier, the name of the action that is to be logged (like "update_event") and an arbitrary bag of data, that is associated with the change.
At least, know we had separated this logic from the rest of the system.
But this approach still has its downsides. We have know logical information,(which action is to be logged) about our business values laying around in the delivery layer. That does not feel right to me.
Since I did not came up with a better solution, I am eager to hear your opinions about this specific problem. I cant be the first one struggling with this! :)