Are Repositories implementations part of my domain? Should repositories have SQL queries?

Question

Are Repository implementations part of my domain model or I should make only abstractions of them part of my domain?

And should I put SQL queries on my repositories or they are placed in another pattern and passed as dependency for my repository?

Thanks

Update

Update 2 Please, take a look at: http://leocavalcante.github.io/patterns/2014/07/11/repository-pattern-and-database-schema.html

Answer 1

If you're using a hexagon, onion or ports and adapters style architecture, then the normal practice is to put your repository interfaces in your domain model and your repository implementations in your persistence layer/adapter. You would then wire them up using an IoC container and add a reference from your persistence layer to your domain model. This allows you to use your domain model entities and value objects in your persistence layer, but also have access to your repositories in your domain model via IoC.

Where you put your SQL is up to you, this isn't particularly a DDD thing, but it probably belongs in your repositories. Standard practice is to use a stored procedure or a LINQ style query using ORM like Entity Framework or NHibernate. In the later case, the query would exist in the repository.

Good practice is for your repositories to accept domain entities (i.e. for creating/updating) and also return domain entities (i.e. for queries). Any auto-generated entities generated by an ORM would normally be hidden by your repositories. This might appear to do-away with a lot of the 'goodness' you get from an ORM (like lazy-loading and 2-way navigation properties), but these things are often a hindrance to good DDD and particularly good object/entity design.

Extra Detail

The repository pattern's goal is to 'act like a list' in order to hide persistence details. So the goal when designing a repository is to make it a simple collection where items can be added, removed and changed. Behind the scenes, your repository can (should) know about where it is storing the data, i.e. a SQL database, flat files, XML files etc.

In DDD you'd ideally want one repository per aggregate root. For example persisting a single Customer aggregate root (an aggregate root may be a single entity, or an entity made up of other entities or value objects) may result in writing to 4 separate tables.