🤖 [Android]구글 권장 아키텍처 <Domain Layer>

Domain layer  |  Android Developers

<해당 내용은 위 공식 문서를 참고하였습니다>

Domain Layer는 UI Layer와 Data Layer 사이에 존재하며, 선택적 요소

복잡한 비즈니스 로직 or 뷰모델에서 재사용되는 간단한 비즈니스 로직 등을 캡슐화 담당

모든 앱에서 반드시 필요한 것은 아니므로, 필요한 경우에만 사용하면 된다.

🎁 내가 몰라서 준비한 IT 사전
[캡슐화] : 객체지향 프로그래밍(OOP)의 개념 중 하나로, 데이터와 해당 데이터를 처리하는 메서드를 하나의 단위로 묶는 것을 의미한다. 이는 외부에서 직접적으로 데이터에 접근하지 못하도록 하고, 오직 정의된 메서드를 통해서만 데이터를 조작할 수 있도록 하는 것을 목표로 한다.

Domain Layer의 이점

• 코드 중복 방지
• 클래스의 가독성 개선
• 앱의 테스트 가능성 향상
• 책임을 분활하면서 대형 클래스가 되는 것을 방지

➡️ 각각의 UseCase에서 하나의 기능만 담당해야하고, 변경 가능한 데이터를 포함해서는 안된다.

변경 가능한 데이터는 UI Layer와 Data Layer에서 처리해야 한다.

📛 Naming Conventions

예시)

FormatDateUseCase

LogOutUserUseCase

GetLatestNewsWithAuthorsUseCase 

MakeLoginRequestUseCase

✨ 의존성

일반적인 앱 아키텍처에서 UseCase는 UI Layer의 ViewModel과 Data Layer의 Repository 사이에 존재

➡️ UseCase는 Repository 클래스에 종속되어 있으며, Repository와 동일한 방법으로 코루틴을 사용하여 UI Layer와 통신

class GetLatestNewsWithAuthorsUseCase(
  private val newsRepository: NewsRepository,
  private val authorsRepository: AuthorsRepository
) { /* ... */ }

위에서 GetLatestNewsWithAuthorsUseCase 는 NewsRepository와 AuthorsRepository 를 결합하여 사용하고 있다.

UseCase는 재사용 가능한 로직을 포함하고 있기 때문에 다른 UseCase에 의해서 사용될 수 있다.

class GetLatestNewsWithAuthorsUseCase(
  private val newsRepository: NewsRepository,
  private val authorsRepository: AuthorsRepository,
  private val formatDateUseCase: FormatDateUseCase
) { /* ... */ }

위의 코드에서 GetLatestNewsWithAuthorsUseCase 안에 FormatDateUseCase를 사용할 수 있는 것을 확인할 수 있다.

🛎️ UseCase 호출 in Kotlin

👩🏻‍💻 Kotlin에서 operator 와 함께 invoke() 함수를 정의하여 UseCase 클래스 인스턴스를 함수처럼 호출하게 만들 수 있다.

class FormatDateUseCase(userRepository: UserRepository) {

    private val formatter = SimpleDateFormat(
        userRepository.getPreferredDateFormat(),
        userRepository.getPreferredLocale()
    )

    operator fun invoke(date: Date): String {
        return formatter.format(date)
    }
}

FormatDateUseCase의 invoke() 메서드를 사용하여 클래스 인스턴스를 함수인 것처럼 호출할 수 있다. invoke() 메서드는 특정한 시그니처에 제한되지 않는다. 매개변수를 개수에 상관없이 취하고 모든 유형을 반환할 수 있다.

class MyViewModel(formatDateUseCase: FormatDateUseCase) : ViewModel() {
    init {
        val today = Calendar.getInstance()
        val todaysDate = formatDateUseCase(today)
        /* ... */
    }
}

FormatDateUseCase 을 MyViewModel에서 위와 같이 호출 할 수 있다.

< invoke() 메서드와 operator 에 대한 자세한 내용은 밑에 링크를 참고해주세요. >

Operator overloading | Kotlin

velog

🌀 생명주기

👩🏻‍💻 UseCase는 따로 생명주기❌ UseCase가 속해있는 클래스의 범위가 적용

➡️ UI Layer의 클래스에서 Service에서 또는 Application 클래스 자체에서 UseCase를 호출

UseCase는 변경 가능한 데이터를 포함 ❌ 

➡️ UseCase 클래스의 새 인스턴스를 종속 항목으로 전달할 때마다 그 인스턴스를 만들어야 한다.

🌸 Threading

Domain Layer에 속하는 UseCase클래스는 메인 스레드에서 안전하게 호출될 수 있어야 한다.

일반적으로 안드로이드 앱에서는 메인 스레드에서는 UI 업데이트를 수행 하고, 메인 스레드를 블로킹하는 작업이 발생하면 앱의 반응성이 저하될 수 있다.

➡️ UseCase 클래스 내에서는 긴 시간이 걸리는 블로킹 작업이 발생할 경우, 해당 작업을 백그라운드 스레드에서 처리하여 메인 스레드의 블로킹을 방지해야 한다.

class MyUseCase(
    private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {

    suspend operator fun invoke(...) = withContext(defaultDispatcher) {
        // Long-running blocking operations happen on a background thread.
    }
}

Kotlin의 코루틴(Coroutine)을 사용하여 백그라운드 스레드에서 작업을 수행하는 방법을 보여주고 있다.

💡 MyUseCase 클래스의 invoke 메서드를 호출할 때에는 해당 작업이 메인 스레드에서 호출되더라도 실제 작업은 백그라운드 스레드에서 수행된다. 이렇게 함으로써 메인 스레드의 블로킹을 방지하고 앱의 반응성을 유지할 수 있다.

긴 시간이 걸리는 작업이 반드시 UseCase 클래스 내에서 처리되어야 하는 것은 아니며, 해당 작업이 다른 레이어에서 더 적합할 수도 있다. 예를 들어, Data Layer에서 데이터를 가져오거나 복잡한 계산을 수행하는 것이 더 적합한 경우도 있다.

🧩 실행 방법

재사용 가능한 비즈니스 로직

UI Layer에 있는 반복 가능한 비즈니스 로직은 UseCase 클래스에서 캡슐화 되어야 한다.

그 로직이 사용된 모든 곳에 변경사항을 더 쉽게 적용할 수 있고 로직을 독립적으로 테스트할 수도 있다.

import java.text.SimpleDateFormat
import java.util.*

class FormatDateUseCase {

    // 메인 스레드에서 안전하게 호출할 수 있도록 suspend 함수로 선언
    suspend operator fun invoke(date: Date): String {
        // 날짜 포맷 형식
        val dateFormat = SimpleDateFormat("yyyy-MM-dd", Locale.getDefault())
        // 주어진 날짜를 포맷에 맞춰서 변환하여 반환
        return dateFormat.format(date)
    }
}

// 사용 예시
fun main() {
    // 현재 날짜를 가져옴
    val currentDate = Date()

    // FormatDateUseCase를 초기화
    val formatDateUseCase = FormatDateUseCase()

    // UseCase를 호출하여 날짜 포맷팅 수행
    val formattedDate = formatDateUseCase(currentDate)

    // 결과 출력
    println("Formatted date: $formattedDate")
}

향후에 날짜 형식과 관련된 비즈니스 요구사항이 변경되는 경우 코드를 중앙에서 한 곳으로 모아 관리할 수 있다.

Repository 결합

News앱이 있다고 가정해보자.

뉴스와 작성자 데이터 작업을 각각 처리하는 NewsRepository 와 AuthorsRepository 가 있을 수 있다.

NewsRepository에서 노출되는 Article 클래스에는 작성자 이름만 포함된다.

❓ 하지만 개발자가 작성자에 대한 자세한 정보를 얻고 싶다면?

이러한 정보는 AuthorsRepository 에서 얻을 수 있겠죠.

이렇게 하나의 로직 안에 여러가지 repository가 포함되어 있는 경우에는GetLatestNewsWithAuthorsUseCase 를 만들어서 ViewModel에서 로직을 추상화하고 가독성을 높일 수 있다. 또한 로직을 보다 쉽게 개별적으로 테스트하고 앱의 다른 부분에서 재사용할 수도 있다.

🙅🏻‍♀️ Data Layer 엑세스 제한

💡 Domain Layer를 구현할 때 고려해야 할 사항은 UI Layer에서 Data Layer에 직접 액세스하도록 허용해야 하는지 아니면 Domain Layer를 통해 모든 것을 강제 적용해야 하는지 여부

🔵 장점 : Domain Layer 로직 위회 방지

Domain Layer의 로직을 UI Layer가 우회하여 접근하는 것을 막는다.

데이터베이스에서 사용자 정보를 가져오는 작업은 Domain Layer의 로직으로 포함 될 수 있는 영역이다. 이러한 로직에는 사용자 인증, 권한 부여, 데이터 검증 및 분석 로깅과 같은 보안 및 로깅 기능이 포함될 수 있다.
하지만 UI Layer가 Domain Layer를 우회하여 Data Layer에 직접 액세스 한다면, 이러한 보안 및 로깅 로직이 우회될 수 있다.
➡️ UI Layer가 직접 데이터베이스에 액세스한다면, 데이터베이스에서 사용자 정보를 가져오는 로직이 Domain Layer를 거치지 않고 바로 실행될 수 있다.
따라서 사용자 인증이나 권한 부여와 같은 중요한 보안 기능이 무시될 수 있다.

이러한 문제를 해결하기 위해, UI Layer는 Domain Layer의 로직을 우회하여 직접 데이터 레이어에 접근하는 것을 막아야 한다. UI Layer는 Domain Layer를 통해 데이터 레이어에 액세스해야 하며, 도메인 레이어의 보안 및 로깅 로직이 항상 실행되도록 보장해야 한다. 이렇게 함으로써 시스템의 보안성과 무결성을 보장할 수 있습니다.

🔴 단점 : 복잡성 증가

단순한 Data Layer에 대한 호출이 있을 때도 UseCase를 추가해야 한다는 점은 복잡성을 증가시킬 수 있다.

💡 필요한 경우에만 사용하고, Data Layer에 대한 접근을 제한할지 여부는 개별 코드베이스에 따라 다를 수 있습니다.
엄격한 규칙이나 유연한 접근 방식 중 어떤 것을 선호하는지에 따라 결정된다.
개발자는 개별 프로젝트의 요구 사항과 선호도에 따라 이러한 접근 방식을 적절히 조절하는 능력이 필요하다.