Z>О! GenericRepository это же чудесно. Вместо того, чтобы писать кучу бесполезного кода, мы его засунем в шаблон и волшебно получим свою порцию бесползеного кода для каждой сущности. Вобщем Specification таки добро оказалось, это радует.

о каком бесполезном коде идёт речь? куда мы что засунем?

Z>То есть, как только я не могу сделать адекватный запрос, я должен вынести Aggregation Root, дать доступ к репозитарию. Ничего, что программисту дают оптимистичные сроки и он не захочет создавать новые репозитарии на простенький запрос? На него же еще и тесты писать придется.

опять глупость. один GenericRepository обслуживает ВСЕ сущности в проекте. один класс с десятком методов по 1-3 строки каждый, пишется не так долго, правда?)

Z>Инкапсуляцию чего? Я привел кучу примеров, когда к неправильному коду приводит именно несвобода написать правильный затратив адекватные усилия. Жду примеров, когда писать неправильный код диктует свобода.

я не вижу ваших примеров. увы.
но в вашем случае, я уже писал. и чуть выше пример приводили. ну нет у вас метода на получение всех мальчиков старше 18 лет, ну и напишет паренёк Users.Where(u => u.Age > 18) по месту в методе, а метод этот вернёт этот же результат в виде IQueriable дальше, где еще кто-то припишет запросик. какой-то.
получим и дублирование кода, и чёрти какие SQL запросы.
в случае использования спецификаций, достаточно будет изменить её одну, что бы получить необходимый результат во всех нужных местах.
плюс вся эта логика обычно обёрнута сервисным уровнем.


Z>Блажен кто верует. Как только данные неожиданно придется отдавать наружу, возникнет сразу столько проблем, что есть репозитарии или нет архитектор уже не заметит. Даже если до этого считал, что репозитарии ему чем-то помогут в данном случае.

где проблемы? какие проблемы? репозиторий помогает унифицировать CRUD операции и абстрагироваться от хранилища данных. этого достаточно.