DDD: Should Persistence Logic belong to Infrastructure Layer?

Question

Well my application follows DDD design principles. It is an ASP.NET MVC application with the MVC web application being the presentation layer(I moved controllers to application layer though). It also has Application Layer that is primarily application services, use cases, etc. Above the Application Layer is the Domain Layer where Domain Models reside. Then there is Infrastructure Layer, which sits on top of everything else, and is supposed to be dependent on no other layers.

But there is one problem I noticed, that if Persistence Logic goes into Infrastructure Layer as the DDD books suggest, the Infrastructure Layer will have dependency to Domain Layer. The Repositories, for instances, need to know the types of Domain Models(Entities) to create, with this knowledge they become dependent on Domain Layer. The original DDD principles however, suggest that Infrastructure Layer should have absolutely no dependency for anything.

So now I am confused, should Persistence Logic really, belong to the Infrastructure Layer? If so, it makes Infrastructure Layer dependent on Domain Layer. If not, then where should it be? Application Layer? Or maybe a separate layer between Application Layer and Domain Layer(as application services use repositories, repositories use domain models). What do you think?

Answer 1

Types of Dependency

I think an important concept that might assist here is to distinguish types of dependency - specifically, a layer or component can be dependent on another layer because either:

1. is defined in terms of concepts defined in that layer, or
2. it uses the other layer - by delegating to that layer (aka calling methods on services in that layer)
3. Or both the above

Inversion of Control and Dependency Injection make this distinction even more important. They guide that we should depend on abstractions rather than concretions.

This means that, for example, the domain layer can define and depend on an abstraction of a repository - e.g. an IEntityRepository interface.

However, the implementation (concretion) is then implemented in the infrastructure layer.

When the application layer wants to call on the repository, it depends on the abstraction (the interface), and the inversion of control system (IoC Container) supplies it with an implementation from the infrastructure layer.

In this case, the infrastructure layer depends on the domain layer - but only in order to know about the interface it is implementing, but it does NOT depend on any other layer in order to delegate to it - it is the last layer in the call stack.

This concept resolves the conflict you were concerned about, because the infrastructure layer doesn't depend on anything else to carry out it's function.

Onion Architecture

Once you start to incorporate IoC concepts into thinking about your architecture, a model that can become very helpful is the onion architecture pattern. In this view, we retain the layered approach, but rather than thinking of it as a stack, think of it as a layered onion, with the Domain in the centre and the interactions with everything outside the application on the edges.

The original DDD books didn't specifically reference this, but it has become a very common pattern for implementing DDD systems.

It is also known as the Ports and Adaptor pattern, or the Hexagonal Architecture.

The idea is that it models dependencies in terms of 'knowing about' in terms of an onion - outer layers know about inner layers but inner layers don't know about outer layers.

But it models delegation of application flow in terms of movement across the onion - from one side of the onion to the other.

To be more specific:

The outer layer (also known as a 'primary adaptor') is where the request enters the system. The adaptor has the responsibility for handling a specific API presentation (e.g. a REST api) and transforming it into a request to the Application services layer - the next layer in. This is often represented as the top-left of the onion.

The Application services layer represents a 'use case' of the application. Typically a method would use a repository interface to retrieve an instance of an aggregate, then delegate to methods on the aggregate root to execute the business logic that involves changing the state of the aggregate as required for the use case. The application services layer, then uses another interface to ask the infrastructure layer to 'save' changes (often using a unit of work abstraction)

Here we have the application layer delegating control flow to an 'outer layer' of the onion (otherwise known as 'secondary adaptors'). This is often represented as the bottom-right of the onion, and is analogous to the 'infrastructure layer' in your description.

And this is where IoC comes in. Because we have an inner layer delegating to an outer layer, it is only possible because the outer layer has implemented an interface defined in an inner layer (which it can do because it knows about the inner layer). However, the IoC container injects the actual concrete implementation which effectively permits the inner layer to delegate control to the outer layer without being dependent on it.

In this conceptualisation, the request has flowed from the top left to the bottom right without the inner layers knowing anything about the outer layers.