Update: I edited my question to make my intentions more clear.So I think this question about logging will be different to the often asked questions.First things first: I have an application that is doing some stuff. While the stuff is beeing done, some situations can occur where the application has to give notice to e.g. some people. To be more concrete, imagine a function that copies a file from A to B. If it succeeds, the function should give notice to the user that started the application by writing something to stdout. If it however fails, it should give notice to this user on stderr but also write to the error to a file and send a mail to e.g. the administrator.Edit: Please note that this is not classical logging in that I want to have some logs for debugging and searching for errors. It is more about a notify system that has the job for deciding how and whom to notify depending on the situation depending on the business-logics.In my opinion the function should not know about who is notified or exactly how to notify. Instead a service should be given to the function that has a method beeing called on success and one for failure. The service then decides what to do next. The methods could be called like providingImportantFileWasSuccessfull and providingImportantFileFailed. (please feel free to give better names here!)So, here comes my question: how to design this service? Or better: how to desing the service architecture. I don't want to make one service class that contains all the business-logic functions as there may be hundreds or even more. Should I create subservices for specific business-logic cases? How could my class-structure look like? Are there other concepts for handling the logging?
Design Logging (or: notify) architecture in application
architecture;logging;notify