Using Infrastructure.Logging in Application Core

[rageshvr]

Implementation of Logging is part of the Infrastructure. Application Core will have it's own service implementation, for instance in this project it is UriComposer. There will be logging required in ApplicationCore, since it is not just the domain entities. How do I make use of Logger in ApplicationCore? Shouldn't this Logger be shared independent project out of infra and core?

[trevor-hackett]

I don't see any issues with how it is implemented. All ApplicationCore, Web, and even Infrastructure needs to know about is IAppLogger. If you need to log in ApplicationCore, you'd inject IAppLogger into your classes. They shouldn't know or care how it is implemented in Infrastructure.

[ardalis]

Correct, what @yarrgh said.

[rageshvr]

So, is it OK to have a Run time dependency to ApplicationCore from Infrastructure?

[ardalis]

Yes, certainly. This follows the Dependency Inversion Principle. Concrete implementations (in Infrastructure) should depend on abstractions (interfaces in ApplicationCore), not vice versa.

[rageshvr]

Infrastructure has a compile time dependency of Application Core, and Application Core has a run time dependency of Infrastructure. Runtime dependency is mentioned in the ebook, but Application Core seems to be isolated from Web App and Infrastructure dependencies. Sort of confused, whether we should have that run time dependency at all to the Application Core.

[ardalis]

Infrastructure has a compile time dependency of Application Core, and Application Core has a run time dependency of Infrastructure.

Exactly.

Runtime dependency is mentioned in the ebook, but Application Core seems to be isolated from Web App and Infrastructure dependencies.

This is by design. The fewer dependencies the ApplicationCore project has, the easier it is to test.

Sort of confused, whether we should have that run time dependency at all to the Application Core.

If you didn't have any runtime dependency, that would imply that the only thing in ApplicationCore was abstractions (e.g. interfaces, abstract base classes). There would be 0 lines of actual executable code. Thus, nothing to test. You need to have your business/domain logic live somewhere. If there were no executable code in ApplicationCore, then your domain logic would either be in Infrastructure (highly coupled, harder to test) or in UI (also not the right place for it).

[ardalis]

The eBook has some references for more reading on Onion Architecture, Clean Architecture. You might benefit from reading those. If you have Pluralsight, I suggest checking out my courses on N-Tier C# apps, Domain-Driven Design Fundamentals, and SOLID Principles of OOP. I can send you a 30-day free pass if you need one. HTH.

[rageshvr]

Thanks Steve. I do have a Pluralsight subscription, I will checkout those courses. I am keen on DDD and Clean architecture, was trying to construct something that abide by the Clean DDD Architecture.

@yarrgh Exactly, core principle is to make the dependencies loose and flexible. Thanks.

[ogix]

Do I understand correctly that if I have IEmailSender, IPushNotificationSender and IUriComposer interfaces in ApplicationCore then EmailSender and PushNotificationSender implementations should be in Infrastructure project (since they depend on 3rd party libs) and UriComposer should be in ApplicationCore (does not depend on libs)? Or is it because EmailSender and PushNotificationSender communicate with external services?

[ardalis]

The rules I follow when using Clean DDD Architecture (as this sample does) are:

1. Minimize dependencies in ApplicationCore; do not depend on anything that depends on infrastructure. So, no references to EF or SendGrid or any other packages that are about out-of-process communication. This keeps ApplicationCore easy to test and easy to depend on without tying the app to a particular infrastructure decision.

2. Making sure to follow rule 1, if you can move something into ApplicationCore, you probably should. This mostly pertains to Services. If you have a Service that sends emails using direct calls to System.Net or some SendGrid client library, it should probably go in Infrastructure since you don't want those dependencies in ApplicationCore. However, if you have a Service that acts at a slightly higher level of abstraction and it "sends emails" by calling an injected interface like ISendEmail, and performs other logic that has no external dependencies, then this service could certainly live in ApplicationCore (since it has no dependencies on external infrastructure or specific implementation details).

Does that help?

[ogix]

It is clear now. Thanks Steve!