Domain driven design repository implementation in infrastructure layer

Question

I got a question on dependencies of DDD layered architecture. If the Repository implementation is in the infrastructure layer, that means that infrastructure layer has a dependency on domain layer because Entities will be referenced in the Repository implementation.

On the other side, the Domain layer can have references to the infrastructure layer if infrastructure services are used in the domain.

Wouldn't this create a cyclic reference?

Answer 1

Yes in your case. And I have the same question :)

Here is my explanation:

It seems that Infrastructure layer is a special one in eric evans' arichitecture diagram. It implements Interfaces, Application, Domain.

This one is kind of farfetched.....

But on the other hander, you could split infrastructure into seperate adapter module since the infrastructure components are typically composed of adapters, translators and facades.

For example,

1)Domain may have a dependence on mailing if you inject a MailManager to a DomainService. 2)Persistence have a dependence on Domain (Repository case).

But if you seperate mailing and persistence into two modules, they have no depedence on each other. I think this may alleviate the problem.

After all, layering is a method to decouple components not a purpose.

Last but not least, I expect more convincible answers :)

Answer 2

Look at the onion architecture it shows a good setup for a DDD solution. (Look at my comment below - use verticial slices instead if you can - cost of onion doesn't seem justified after using for years)

Basically all domain model and interfaces for domain services are considered core. Layers depend only on layers above them that are closer to the core. Their actual implementation is handled by infrastructure.

Domain project shouldn't reference infrastructure project. If domain needs to use something it should be defined as an interface within domain and implemented in the infrastructure project.

Ultimately your interfaces are what defines your application. The logic of how that gets implemented is externalised. So I'd expect you to have assemblies with Domain Models and domain services, a front end (e.g. MVC etc) and then an infrastructure assembly that implements things like NHibernate for providing data etc.

You can see various samples that implement the architecture in the various parts of the linked article. The simplest one is here

You can see questions related to it here

The main benefit is that it is largely the infrastructural concerns that will change the most often. New data layer technologies, new file storage, etc. Also, your core domain should be reasonably stable as it isn't implementing anything just defining by contract(interfaces) what it requires. By putting the implementation concerns in one location you minimise the amount of changes that will be required across your assemblies.