Where to define the interfaces for a repository in an layered architecture?

Question

Background

I\'m trying to create a simple application to really understand the whole stack of DDD+TDD+etc. My goal is to dynamically inject the DAL repo

Answer 1

I agree with eulerfx. The only thing I would add to it is that it doesn't feel right because traditional N-tier architecture would have you make everything depend upon the database and use abstractions to break those dependencies.

You should look at Onion Architecture which is an example of the way you are organizing your dependencies in option 4. I, personally, believe this is the most scalable architecture model available. If you couple this architecture with DDD practices, you gain the most flexibility with the least amount of effort.

On a side note, many implementations I have seen break out the contracts for the repositories and domain services into its own project. This is purely an organizational decision though. It is perfectly valid to have them within your domain model project.

Answer 2

From what I understand of your question, I would agree that option 4 is the best. The repository interfaces should be declared in the domain layer next to all of the domain objects. The implementation of said interfaces should be part of the infrastructure layer - the layer that connects your domain layer to the world. Take a look at the Hexagonal Architecture to see some of the motivation for this.

To address the con of option 4, you shouldn't think of the console app as being solely the presentation layer. It also has other responsibilities, such as being the host for the application and the composition root in DI terms. There could be a presentation component of the console app which only communicates with application services. You can also encapsulate the application service behind an open host service implemented with ASP.NET WebAPI. Then the presentation layer would only reference this service and be hidden from the underlying domain layer.