Какую архитектуру использовал?

Моя архитектурная практика в Android-разработке

За свою карьеру я использовал несколько архитектурных подходов, эволюционируя вместе с экосистемой Android. Я не придерживаюсь догматично одной архитектуры, а выбираю подход в зависимости от масштаба проекта, команды и конкретных требований. Однако есть фундаментальные принципы, которые остаются неизменными.

MVVM (Model-View-ViewModel) + Clean Architecture

В последние 5 лет это моя основная архитектура для большинства проектов. Она идеально сочетается с реактивным программированием и компонентами Android Jetpack.

// Пример структуры слоев по Clean Architecture
// presentation/
class UserViewModel @ViewModelInject constructor(
    private val getUserUseCase: GetUserUseCase,
    private val saveUserUseCase: SaveUserUseCase
) : ViewModel() {
    private val _userState = MutableStateFlow<UserState>(UserState.Loading)
    val userState: StateFlow<UserState> = _userState.asStateFlow()
    
    fun loadUser(userId: String) {
        viewModelScope.launch {
            _userState.value = UserState.Loading
            try {
                val user = getUserUseCase.execute(userId)
                _userState.value = UserState.Success(user)
            } catch (e: Exception) {
                _userState.value = UserState.Error(e.message ?: "Unknown error")
            }
        }
    }
}

// domain/
class GetUserUseCase @Inject constructor(
    private val userRepository: UserRepository
) {
    suspend operator fun invoke(userId: String): User {
        return userRepository.getUser(userId)
    }
}

// data/
class UserRepositoryImpl @Inject constructor(
    private val userRemoteDataSource: UserRemoteDataSource,
    private val userLocalDataSource: UserLocalDataSource
) : UserRepository {
    override suspend fun getUser(userId: String): User {
        // Бизнес-логика кэширования
        val localUser = userLocalDataSource.getUser(userId)
        return if (localUser != null && !isCacheExpired(localUser)) {
            localUser
        } else {
            val remoteUser = userRemoteDataSource.getUser(userId)
            userLocalDataSource.saveUser(remoteUser)
            remoteUser
        }
    }
}

Ключевые принципы, которые я соблюдаю независимо от архитектуры:

1. Разделение ответственности - каждый класс/модуль выполняет одну четкую задачу
2. Односторонний поток данных (Unidirectional Data Flow) - данные всегда движутся в одном направлении, что упрощает отладку и тестирование
3. Зависимость от абстракций - Dependency Injection через Dagger/Hilt или Koin
4. Реактивное программирование с Kotlin Flow/Coroutines или RxJava

Выбор архитектуры в зависимости от контекста:

Для больших enterprise-проектов:

• Clean Architecture + MVVM с четким разделением на data/domain/presentation слои
• Модульная архитектура с dynamic feature modules
• Использование MVI (Model-View-Intent) для сложных экранов с множеством состояний

// Пример MVI подхода
sealed class LoginState {
    object Idle : LoginState()
    object Loading : LoginState()
    data class Success(val user: User) : LoginState()
    data class Error(val message: String) : LoginState()
}

sealed class LoginIntent {
    data class Login(val email: String, val password: String) : LoginIntent()
    object ClearError : LoginIntent()
}

Для средних проектов:

• Упрощенный MVVM с Repository pattern
• Использование Android Architecture Components
• Single Activity с Navigation Component

Для прототипов и небольших приложений:

• MVC или упрощенный MVVM без чрезмерного усложнения
• Focus на быстрой разработке с возможностью рефакторинга позже

Технологический стек, который я обычно комбинирую с архитектурой:

• DI: Dagger Hilt (предпочтительно) или Koin
• Асинхронность: Kotlin Coroutines + Flow
• Локальная БД: Room с Flow для наблюдения за изменениями
• Сетевое взаимодействие: Retrofit + Moshi/Gson
• Кэширование: сочетание Room для persistence cache и memory cache при необходимости
• Навигация: Jetpack Navigation Component
• UI State management: ViewModel + StateFlow/SharedFlow

Эволюция моего подхода:

Раньше я активно использовал MVP (Model-View-Presenter), который до сих пор хорошо подходит для некоторых проектов, особенно с Legacy кодом. Переход на MVVM стал естественным с появлением Architecture Components и реактивного программирования в Kotlin.

Сейчас я также экспериментирую с MVI и Composable Architecture для проектов, полностью написанных на Jetpack Compose, где UI становится функцией состояния.

Важнее конкретного названия архитектуры я считаю соблюдение принципов SOLID, KISS и YAGNI. Архитектура должна служить проекту, а не наоборот. Она должна обеспечивать тестируемость, поддерживаемость и масштабируемость, но не становиться самоцелью.

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