Question

i’ve read a blog about DDD from Matt Petters

and according and there it is said that we create a repository (interface) for each entity and after that we create a RepositoryFactory that is going to give instances (declared as interfaces) of repositories

is this how project are done using DDD ?

i mean, i saw projects that i thought that they use DDD but they were calling each repository directly, there was no factory involved

and also

why do we need to create so much repository classes, why not use something like

public interface IRepository : IDisposable
{
T[] GetAll();
T[] GetAll(Expression<Func> filter); 
T GetSingle(Expression<Func> filter); 
T GetSingle(Expression<Func> filter, List<Expression<Func>> subSelectors); 
void Delete(T entity); 
void Add(T entity); 
int SaveChanges(); 
}

i guess it could be something with violating the SOLID principles, or something else ?

Answer 1

There are many different ways of doing it. There’s is not single ‘right’ way of doing it. Most people prefer a Repository per Entity because it lets them vary Domain Services in a more granular way. This definitely fits the ‘S’ in SOLID.

When it comes to factories, they should only be used when they add value. If all they do is to wrap a new operation, they don’t add value.

Here are some scenarios in which factories add value:

• Abtract Factories lets you vary Repository implementations independently of client code. This fits well with the ‘L’ in SOLID, but you could also achieve the same effect by using DI to inject the Repository into the Domain Service that requires it.
• When the creation of an object in itself is such a complex operation (i.e. in involves much more than just creating a new instance) that it is best encapsulated behind an API.