Android чистая архитектура и связанные объекты

Question

Это в основном вопрос дизайна. У меня есть 2 лица Payment а также User, имея отношения один-к-одному. Вызов API возвращает список Payments каждый Payment содержит User, Платежи отображаются в представлении Recycler, каждая строка содержит информацию как из Payment а также User юридические лица. И чтобы извлечь их из БД (используя Room), мне нужно выполнить запрос на соединение, который возвращает комбинацию обеих сущностей:

@Query("SELECT payment.*, user.* FROM payment INNER JOIN user ON payment.user_id = user.userId")
fun findPaymentsAndUsers(): List<PaymentAndUser>

data class PaymentAndUser(
    @Embedded val payment: Payment,
    @Embedded val user: User)

У меня вопрос: как я могу создавать свои репозитории, не нарушая ни одного из принципов чистой архитектуры?

• Конечно, я не могу создать 2 независимых репозитория и передавать данные между ними через вызывающий UseCase, потому что они уже возвращаются вместе либо в вызове API, либо в запросе Room DAO.
• Принцип единой ответственности гласит, что каждый репозиторий должен обрабатывать только свою собственную сущность, поэтому я не могу создать PaymentRepository и обрабатывать все оттуда.
• Я также не могу сгруппировать обе сущности в Агрегат и создать репозиторий, который обрабатывает их обе, потому что они являются двумя независимыми сущностями, которые могут существовать независимо друг от друга.

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

Есть ли способ, которым это может быть реализовано правильно?

Answer 1

Что касается моего понимания, SRP НЕ говорит, что каждый репозиторий должен обрабатывать только свою собственную сущность - вместо этого у каждого репозитория должна быть только "одна причина, которую нужно изменить".

Паттерн, который должен решить вашу проблему - это паттерн "единицы работы": просто создайте репозиторий "единицы работы", который точно обрабатывает этот запрос.

На самом деле в своей книге "Чистая архитектура" дядя Блоб утверждает, что интерфейсы репозитория должны быть спроектированы так, чтобы это было удобно для пользователя. У него должен быть один метод "на запрос", который будет использовать сценарий использования с хранилищем.