Where logging should go in onion architecture with DDD

Question

I am developing a console application using onion architecture and domain driven design. I have a two domains, where I need to implement logging, I confused where I can place the logging component. Can I place that in respective infrastructure of two domains? Or In shared kernel which can be referenced in both the domains? If I need to place it in the shared kernel what is the structure I should follow?, I mean like core, infrastructure.

Dedicated

Answer 1

Logging is a cross-cutting concern. aspect-oriented programming aims to encapsulate cross-cutting concerns into aspects. This allows for the clean isolation and reuse of code addressing the cross-cutting concern.

You need to create a library and implement your logging classes, something like "MyProject.CrossCutting.Logging" And use aspect-oriented approaches to log the events using this library.

Fowle

That sounds right, but that generally would mean that there is one centralized log, but what if you want to save events for aggregates - they probably would have the same structure, but they should be encapsulated (accessible only through aggregate root), so what if I have events per each aggregate - like SalesEvent, CustomerEvent. Then according to DDD it should be Aggregate root's responsibility to process those events, wouldn't it? Or maybe it would still mean that logger is in infrasture and aggregate root is calling it "save my events", but how would logger resolve where to store? – Odd

@Odd IMHO logs must be emitted out of application as soon as possible in a unified way for whole application - because logs are used for debugging and if application crash in unexpected way before logs are emitted they would be lost. And thus one centralized log per application makes most sense. Logs can be decentralized later if necessary based on tags by log processor that works outside the application. Events are different than logs. Events can be emitted by repository only after aggregate was successfully committed to database, discarding them if commit fail is expected. – Mor

Answer 2

Logging is cross-cutting across all of your applications. That should be part of your framework. All of the layers of all of your application projects can have dependency on your framework, the same way they have dependency on .Net Framework, Spring, etc. Your framework must have abstractions for cross-cutting concerns that you can easily rely on, and then the implementation just has to be referenced in the composition root of the application which is in the infrastructure.

Wetzel

Answer 3

If you're following DDD and the Onion Architecture, it doesn't matter how many domains you have. Each Domain can implement their own version of a Logger if needed. More than likely, you will create a Logging Interface and possibly a static Implementation that is kept in Common Layer that can be called by any of the Layers that needed it. In the image that was shared previously, it would be kept in Cross-Cutting Layer. As previously mentioned, Logging is a concern of all layers.

Floats

As per the previous suggestion, what we done is, we created a interface for logger in core and concrete implementation in shared kernel, we are injecting this concrete implementation to core from main program which using services of core. am i going in right direction? – Dedicated

@MaheshkumarCh Logging is not a domain concern. It shouldn't be in any domain model, whether it be shared kernel or standalone domain. – Commonwealth

Then where logging should go? I am using onion architecture. I am using logging in the services to log all operations. – Dedicated

Logging is setup in the UI (Console, ASP.NET Core, etc.) and then injected into Infrastructure. – Walkway

So, being a pure infrastructure service, would the interface and implementation of the Logger be defined at the infrastructure layer? – Dowdell