разработки и поддержки кода.
Если возникает необходимость полдня чесать репу и думать что куда поместить - то нафиг тогда этот clean?
По опыту репозиторий лучше воспринимать как тонкую обертку (=data source).
Объясню почему.
Вот вы, джедай клина, пишите репозиторий, который объединяет 2 дата-сорса (net и db). Ok, всё круто.
Потом приходит другой разраб. Ага, надо перед запросом прочитать настройку. Чешет репу, куда поместить дата сорс настроек. Аха, настройка связана с данным запросом, значит в репозиторий. Потом другой разраб хочет ещё один запрос сделать. Чешет репу, добавляет в тот же репозиторий. Третий разраб хочет ещё писать настройки ..
В итоге в репозитории получаются инжнкекты левых дата-сорсов, других репозиториев и другой хрени.
А потом... Этот репозиторий понадобилось переиспользовать, но без настроек. Что делает 4-й разраб? Правильно, добавляет флажки в параметры методов. Или того хуже, добавляет state в репозиторий.
Так что лучше всё-таки дать установку, что репозиторий - тонкая обертка. Чтобы не чесать репу что в него пихать.
То есть если сначала писать по клину, потом дорабатывать не по клину, то всё посыпется. Поэтому мы делаем вывод, что лучше сразу писать не по клину?
тогда для каждой фичи нужен отдельный репо, без переиспользования
Репозитории - это слой данных. Его имплементация может быть вообще в отдельном модуле. И он как раз может переиспользоваться. Сущность, которая работает с несколькими дата-сорсами (репозиториями) - это скорее интерактор, но на самом нижем уровне. В бизнес-логике может быть несколько слоёв. На нижнем уровне может быть интерактор, который работает с несколькими репозиториями. Но этот слой уже принадлежит фиче, а не имплементации репозитория
картинку уже давно бы нарисовал )
Я говорил о том, что каждая фича в своем домене держит один или несколько интерфейсов репозитория, под каждый кейс. Без переиспользования. Надо сохранять данные - один репо. Надо сохранять еще и настройки и т.д. - другой.
Где имплементация этих репозиториев?
Обсуждают сегодня