Здравствуйте, zelenprog, Вы писали:

Насчёт DDD.

Z>Проблема: Один Repository на всех
Z>Попытка создать один универсальный Repository для всех доменных сущностей всегда оборачивается нарушением принципа единственности ответственности и разрастанием этого Repository. Зачастую такие универсальные решения нарушают принцип открытости/закрытости (пример с Repository).
Нет, здесь под понятием "универсальный" понимается не репозиторий с методами для всех сущностей, а решение типа Repository<T> — один параметризованный класс для всех типов сущностей.

Z>Но ведь у меня "Аналог" и "Упаковка" — это же корни агрегации.
Z>Значит для них нужны отдельные репозитории.

Наоборот, корень агрегации — это Tovar, а Аналоги и Упаковки — подчиненные ему сущности. Поэтому по канонам DDD здесь нужно создавать один репозиторий — TovarRepository с методом типа GetTovarWithAnalogAndPack().

Но еще следует помнить про bounded context из DDD. В вашем сценарии, действительно, Tovar — корень агрегации. Но в других сценариях, например, вы пишете админку с редактирование справочников, Аналоги и Упаковки тоже могут быть корнями.
И что же, вы спросите, теперь плодить отдельные почти одинаковые сущности под каждый сценарий? Насколько я понимаю DDD, да, придется. Хоть это и усложнит систему в целом, но зато упростит каждый отдельный контекст. Но ведь DDD подход и предназначен для сложных систем, в простых он только даёт ненужный оверхед. ИМХО.

Насчет временной таблицы уже написали выше. Могу только добавить что в нормальных СУБД временные таблицы имею видимость, ограниченную чем-то: соединением или пользователем. Так что при правильном подходе можно, наверное, избежать конфликта данных во временной таблице при одновременных запросах. Есть и другие подходы, см. тут

Зы: а еще лучше вместо паттерна "репозиторий" использовать что-то типа Query Object или Command. Каждый запрос в отдельном классе. В конструктор инжектим только необходимое.

Здравствуйте, zelenprog, Вы писали:

Насчёт DDD.

Z>Проблема: Один Repository на всех
Z>Попытка создать один универсальный Repository для всех доменных сущностей всегда оборачивается нарушением принципа единственности ответственности и разрастанием этого Repository. Зачастую такие универсальные решения нарушают принцип открытости/закрытости (пример с Repository).
Нет, здесь под понятием "универсальный" понимается не репозиторий с методами для всех сущностей, а решение типа Repository<T> — один параметризованный класс для всех типов сущностей.

Z>Но ведь у меня "Аналог" и "Упаковка" — это же корни агрегации.
Z>Значит для них нужны отдельные репозитории.

Наоборот, корень агрегации — это Tovar, а Аналоги и Упаковки — подчиненные ему сущности. Поэтому по канонам DDD здесь нужно создавать один репозиторий — TovarRepository с методом типа GetTovarWithAnalogAndPack().

Но еще следует помнить про bounded context из DDD. В вашем сценарии, действительно, Tovar — корень агрегации. Но в других сценариях, например, вы пишете админку с редактирование справочников, Аналоги и Упаковки тоже могут быть корнями.
И что же, вы спросите, теперь плодить отдельные почти одинаковые сущности под каждый сценарий? Насколько я понимаю DDD, да, придется. Хоть это и усложнит систему в целом, но зато упростит каждый отдельный контекст. Но ведь DDD подход и предназначен для сложных систем, в простых он только даёт ненужный оверхед. ИМХО.

Насчет временной таблицы уже написали выше. Могу только добавить что в нормальных СУБД временные таблицы имею видимость, ограниченную чем-то: соединением или пользователем. Так что при правильном подходе можно, наверное, избежать конфликта данных во временной таблице при одновременных запросах. Есть и другие подходы, см. тут

Зы: а еще лучше вместо паттерна "репозиторий" использовать что-то типа Query Object или Command. Каждый запрос в отдельном классе. В конструктор инжектим только необходимое.