Where should logging logic sit within a DDD solution?

Question

I've created a custom filter for my MVC application, [LogAttribute]. Action methods are decorated with this and it has the responsibility to create a LogEntry object to pass into some type of provider - ILoggerProvider.

My question is, where should ILoggerProvider and it's implementations sit (I'll be wanting to use a DI technology on it)? Should they go in the domain model, the UI project or a separate class?

Answer 1

Hi.
Since logging has nothing to do with UI, this is definetly the wrong place. The domain model is there for data representation in my opinion. So i would do it in a seperate class or even a seperate project.

I have a MVC application where i have a seperate project for a logging service. In my structure it is in the most bottom layer (data access) since it directly logs to files and all other services are using it. I also use DI on it with use of the MEF framework.

This has been working fine for me for a while and i didn't want to change it since then. I had other solutions which i skipped after a while because they were not as elegant to use as my current solution.

Hope that helps you with your decision.

Answer 2

I'd generally contend that ILoggingProvider should sit within the domain model for a few reasons. From a logistics and sanity perspective, your domain classes probably need to reference the logger. From a DDD perspective, given the world of SOX and such we live in, one can argue that logging is a core domain feature for regulatory compliance.

Now, the implementations can definitely sit off in your infrastructure projects, no need to clutter the model with all that.

Answer 3

Unless your software's primary function is Logging or Auditing, it should be an Infrastructure LoggingService.

And unless your logging implementation is tightly-coupled with your Domain Objects (I hope it isn't!), I would suggest a completely separate assembly.