DDD Хранилище и заводы

Question

Я прочитал blog about DDD from Matt Petters

и согласно и там сказано, что мы создаем хранилище (интерфейс) для каждого объекта, и после этого мы создаем RepositoryFactory, который собирается дать экземпляры (объявленный как интерфейсы) репозиториев

Это как проект осуществляется с использованием DDD?

я имею в виду, я видел проекты, которые я думал, что они используют DDD, но они звонили каждый хранилищу напрямую, не было ни одного завода не участвует

, а также

почему нам нужно создать столько классов репозитория , почему бы не использовать что-то вроде

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(); 
} 

Возможно, это может быть что-то, что нарушает принципы SOLID или что-то еще?

Answer 1

Существует много разных способов сделать это. Там нет единого «правильного» способа сделать это. Большинство людей предпочитают репозиторий для каждого объекта, поскольку он позволяет им изменять доменные службы более подробно. Это определенно соответствует «S» в SOLID.

Когда дело доходит до фабрик, их следует использовать только тогда, когда они добавляют ценность. Если все, что они делают, это обернуть операцию new, они не добавят значения.

Вот несколько сценариев, в которых заводы увеличивают стоимость:

• Abtract Фабрика позволяет варьировать Repository реализации независимо от клиентского кода. Это хорошо сочетается с «L» в SOLID, но вы также можете добиться такого же эффекта, используя DI, чтобы внедрить репозиторий в требуемую ему службу домена.
• Когда создание объекта само по себе является такой сложной операцией (т. Е. Вовлекает гораздо больше, чем просто создание нового экземпляра), оно лучше всего инкапсулируется за API.