МСУОбвязка в репозиторий решает 100% задач. Всё остальное высосано из пальца.Дык в статье и про это написано. Репозиторий решает, но просто он разрастается настолько, что тупо mock-и уже хрен напишешь.
Да и принцип single responsibility начинает нарушаться с появлением требований возвращать такие-то и сякие-то наборы данных.
А когда эти данные надо ещё кэшировать, или нет, индексировать, или нет, то начинаются сложности плюс всё новые и новые зависимости.

Хорошо вам, у вас этого нет.
А мне в ходе эволюции бизнес-требований приходится сталкиваться с тем, что удаление поля из колонки приводит к тому, что надо рефакторить код в 10 местах, написанных 5-ю различными "неговноархитекторами" :)

ViPRosskyANAпропущено...
Ну да, весь мир же на самом деле работает с монолитными системами типа Випрос :)

Мобильную версию прикрутите когда-нибудь, или гордо почите в базе?
ну не нужно это в ВПК
там нет интернета даже :)Когда в следующий раз полетишь отдыхать в Испанию, то лети на Ан-12

ViPRosskyANA,

вот если бы кода не было, то и не надо было бы ничего рефакторитьрасскажешь, что будет, если Дмитрий Анатольевич захочет с ётафона через Випрос ВПК рулить

МСУskyANAРепозиторий решает, но просто он разрастается настолько, что тупо mock-и уже хрен напишешь.
Всё это нытьё на пустом месте, декомпозиция репозиториев решает. EmployeesRepository, CompanyRepository, StateRepository и так далее.

skyANAДа и принцип single responsibility начинает нарушаться с появлением требований возвращать такие-то и сякие-то наборы данных.
А когда эти данные надо ещё кэшировать, или нет, индексировать, или нет, то начинаются сложности плюс всё новые и новые зависимости.
Кеширование и прочие грабли - не задача репозитория. Задача репозитория - выдать данные по параметрам. Всё.Всё верно.

Но наступит тот момент, что и Employees, и Company, и State будут использоваться в каком-то одном бизнес-процессе.
В каких-нибудь продажах.
И надо будет вернуть Employees, что участвуют в продажах. Companies, что участвуют в продажах. States, что участвуют в продажах.
А потом добавится ещё биллинг.
И надо будет вернуть Employees, что участвуют в биллинге. Companies, что участвуют в биллинге. States, что участвуют в биллинге.

И т.д., и т.п. :)

А кэширование всё-таки задача репозитория. Вернее работа с кэшем.
Данные хранятся в распределённом кэше Redis-а. Если их там нет, то берутся из БД.

Репозиторий как раз таки и обеспечивает прозрачность доступа к данным :)

Но ты наверное о другом каком-то кэше.

Алексей КskyANAпропущено...
Всё верно.

Но наступит тот момент, что и Employees, и Company, и State будут использоваться в каком-то одном бизнес-процессе.
В каких-нибудь продажах.
И надо будет вернуть Employees, что участвуют в продажах. Companies, что участвуют в продажах. States, что участвуют в продажах.
А потом добавится ещё биллинг.
И надо будет вернуть Employees, что участвуют в биллинге. Companies, что участвуют в биллинге. States, что участвуют в биллинге.

И т.д., и т.п. :)Обычная ситуация, проблем не вижу, всегда с этим жили. :-)Да проблем-то нет. Пока не слишком дорого вносить изменения и перепроверять после этого :)

Пока одно хранилище, тестами ни фига не покрыто, если что-то падает, то падает в большой лог, с которым когда-нибудь разберутся, то всё нормуль.

А вообще CQRS и репозиторий со спецификациями и прочими квери обджектами прекрасно уживаются вместе.
Надеюсь вы не подумали, что я предлагаю переписать всё на CQRS? :)

ViPRosskyANA,

ну падать допустим воще последнее дело
а тесты все равно нифига не решают ничего
вот тут типа тестер хотел пристроиться
я ему грю - докажи что это расписание не оптимальноНу что они решают? Тупо сразу показывают, что твои изменения поломали.
Решаешь потом ты, как разработчик: сам дурак, или тесты кривые :)

Сильно экономят время.

Ну и скажи нашему ВПК, что тестовые пуски ракет ни фига не решают