Domain driven design repository implementation in infrastructure layer
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
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.