Repository и единый источник истины

Один путь чтения

Repository определяет политику работы с данными: откуда читать, как обновлять и что считать актуальным. В рассматриваемой offline-first модели UI наблюдает локальную базу. Сеть обновляет базу, а изменения доходят до UI через тот же путь чтения. Это уменьшает риск расхождения сетевого результата и локального кеша. Offline-first.

Разделите наблюдение и обновление

interface NotesRepository {
    fun observe(): Flow<List<Note>>
    suspend fun refresh()
}

Здесь Flow — kotlinx.coroutines.flow.Flow, Note — доменная модель приложения. refresh не отдаёт UI независимую вторую копию данных, а записывает результат в локальный источник. Ошибка сети может сосуществовать с доступным кешем: не стирайте полезное содержимое только ради флага ошибки. Offline-first.

Источник истины не устраняет конфликты

Сервер и устройство могут принять разные изменения офлайн. Нужна явная политика: версия записи, конфликт с ручным выбором, last-write-wins с оговорками или предметное слияние. Один Repository сам по себе не превращает эти операции в транзакцию.

В нашем сценарии список с сервера заменяется в базе атомарно, а повторная отправка использует прежний ID операции. Это решения для заданных требований; для совместного редактора может понадобиться другая модель согласования.

Цена дополнительного слоя

Repository полезен, когда скрывает политику данных. Use case добавляют ради сложной или повторяемой логики; одноимённая прокладка для каждого метода не является обязательным условием хорошей архитектуры. Domain layer.

Основа отбора: draft/Architecture interview.md, draft/M++.md, draft/faq500.md.