Architectural solution for business logging

Question

I have a the requirement for a webservice which should return a "business log" of the action the service performed. Usually I only return error logs which are based on exceptions. the exceptions get aggregated to a log at the top most level in the webservice.

Injecting a logger-object into every business class so it could write to the "business log" seems to be a solution, but it pollutes my code with a lot of logging-commands inside the business code. Also every constructer has to be modified. Adding an attribute to every class which includes the log messages also looks strange to me. Is there any other solution?

Answer 1

There's really not enough information about the expected contents of the business log. Generally, I see the following approaches:

1. If the logging can be modeled as a cross-cutting concern, you could use some appropriate technology like an aspect framework or interceptors. (In Java that would e.g. be AspectJ or an interceptor in a CDI container)

2. You could wrap the business classes with logging facades, which implement the same interface, perform the logging, and then delegate to the real business class.

3. If none of these is appropriate (e.g. because you need real in-depth logging of each step a method takes) I cannot see any way without polluting your code with logs.

Answer 2

Your business logger needs to communicate with other out-of-process services for data storage. This means, you need to decouple this logger from your business logic, so you could easy mock it in unit tests or replace with another logger implementation based on the same logger interface, that will be expected in client code.

You wrote, that your logs are based on exception is thrown. This doesn't look correct solution for business logger, because you may want store log information regarding successful operations, provide "info" or "warning" priority logs additionally to "error" kind of records. You also may want to post more than one business log per single action.

You should distinguish between business logging and support logging, where business logs describe business processes and problems for clients of your application, but support logs provide information for developers and QA. It is often useless to decouple support log service to separate dependency, but you may want to separate it too.