Should application layer depend on infrastructure layer in DDD?

Question

I read that application service is used to orchestrate, they handle workflows of an application.

Eg: After transferring money from user A to user B, system must send email.

So application service calls domain entities, domain services to process domain logic. Then call infrastructure to send email. Then application layer depends on domain layer and infrastructure layer. Does it violate DDD? Should application layer depend on infrastructure layer in DDD?

Organon

Answer 1

Should application layer depend on infrastructure layer in DDD?

I believe that the pattern you are looking for is "service provider".

The application component would define the interface / api / contract that it needs satisfied to fulfill its own responsibilities

The infrastructure component provides an implementation of this interface

The composition root creates the infrastructure component, and in turn uses that to create the application component.

In automated tests of the application, you will probably include the domain component, but replace the infrastructure component with a test double.

Boil

Answer 2

I don't think that would violate any DDD principle, but I'm not a DDD purist so I'm not sure.

Perhaps this can be helpful: http://dddsample.sourceforge.net/architecture.html

"In addition to the three vertical layers, there is also the infrastructure. As the the picture shows, it supports all of the three layers in different ways, facilitating communication between the layers."

I believe an email service would be considered as an external service, and thus belong to the infrastructure.

Bughouse

Answer 3

Should application layer depend on infrastructure layer in DDD?

Yes you can ! Application services declare dependencies on infrastructural services required to execute domain logic.

But if you can avoid it by using interfaces it will be better for more isolation (ports, adapters)

Veritable

Answer 4

When thinking of a layered architecture there is in general the distinction between a strict or relaxed layered architecture.

In a relaxed layered approach a layer is “allowed” to access any lower layer, not just the one immediately below (wich would be the strict approach).

In my personal opinion the relayed approach is pracmatic and perfectly okay with DDD - one should not be to dogmatic with the layers.

We for example decided for the relaxed approach and use it exactly the way you described it. From the application services we orchestrate the usecases by utilising the building blocks of the domain layer as well as infrastructure components (i.e. for notifications like email).

PS: above just as a general clarification if it violates DDD. Of course you should technically prevent tight coupling of the layers by using DI, maybe with strategy pattern, ...

Supinate