Архитектура бывает двух типов:
- На которой идёт быстрая разработка
- Удобная для поддержки проекта
Нужно отделять бизнес логику от деталей. Для начала это может быть обращение к интерфейсу, и вам не важно что в дальнейшем у методов этого интерфейса поменяется реализация.
Нужно использовать сервисы и репозитории, в качестве абстракций к моделям. На практике это означает, что у контекста (например аккаунт) есть свой сервис - класс, где сосредоточена бизнес логика, и репозиторий - класс посредник для обращения к базовому репозиторию с методами запроса к базе данных.
Что касательно вашей ситуации, то вам следует опираться на принцип "Единственной ответственности", суть которого в том, что к каждого компонента может быть только одна причина для изменения.
Таким образом, причина для изменения логики работы с городами, не должна быть причиной изменения в коде, который работает с магазинами.
Лучше идти от большего к меньшему, то есть сначала использовать дублирование кода в разных контекстах, а потом провести рефакторинг и вынести все что нужно в отдельные классы.
Если вы будете использовать контексты, и выстраивать взаимодействие между ними, через классы посредники, вы поймёте, что дублирования кода нет, так как сам контекст уже содержит в себе логику, к которой обращаются несколько других контекстов.
