Log based on use cases

You will most likely check the log after receiving a ticket and a ticket will most likely say something like "Operation use case for object not working in application".

Taking that into consideration, the easiest approach to logging is to:

• create one log object per application
• create one subobject per use case
• use the technical ID of the processed object as an external ID whenever possible

If you stick to that pattern, finding the right log will become very easy, as the ticket will contain all the filters you need.

It is also highly recommended, to have one dedicated handler method or form per use case (e.g. create invoice, delete user, etc.). This handler method should:

• create the log writer
• claim it
• call the actuall processing logic
• save the log
• destroy the log

This defines a single point of responsibility for creating and destroying the log, so that no method down the call chain has to deal with that.