Domain layer란 무엇일까?

• 안드로이드에서 가장 안쪽에 있는 layer이며, 순수 비즈니스 로직과 앱의 핵심 규칙을 정의하는 layer 를 말한다.
• 밥 아저씨의 클린 아키텍처에서 Entity와 UseCases 부분이다.

Entity & UseCase

• Entity
  • 앱의 비즈니스 도메인을 표현하는 객체이며, domain layer에서 데이터 클래스라고 생각하면 된다.
• UseCase
  • 앱에서 실행되는 비즈니스 프로세스를 캡슐화하는 역할을 가지고 있다. 즉, 데이터가 어떻게 사용되고 어떤 절차로 실행되어야 하는지 규칙을 정의하는 곳이라고 생각하면 된다.
  • 단일 책임 원칙 (Single Responsibility Principle) 을 준수해야 한다. 하나의 Use Case는 하나의 비즈니스 로직만을 처리해야 한다.
  • 비즈니스 로직를 수행할 때는 Repository 를 사용하여 수행한다.

Repository

• Domain layer와 DataSource(data layer)를 연결하는 추상화하며, 다양한 데이터 소스를 통합적으로 처리하는 책임도 있습니다.
  • 즉, 도메인 계층에서 데이터를 요청하고, 데이터 계층에서 가져온 데이터를 비즈니스 규칙에 맞게 변환하거나 통합하여 제공한다.
• Domain layer에서는 Repository의 구현을 알지 못하며, interface만 사용한다.
• Data Base, API, 캐시 등 어떤 DataSource를 사용하는지 모른다.

테스트 코드

• 비즈니스 로직이 변경되더라도 유닛 테스트를 통해 안정성을 검증할 수 있도록 테스트 코드 작성
• UseCase를 테스트 가능
• DB나 API 상관없이 단위 테스트 가능

class GetUserDetailsUseCaseTest {
    private val userRepository = mock<UserRepository>()
    private val getUserDetailsUseCase = GetUserDetailsUseCase(userRepository)

    @Test
    fun `when valid userId is provided, returns user details`() = runBlocking {
        val userId = "123"
        val expectedUser = User("123", "John Doe")
        whenever(userRepository.getUserById(userId)).thenReturn(expectedUser)

        val result = getUserDetailsUseCase.execute(userId)

        assertEquals(expectedUser, result)
    }
}

요약

• 서버의 API나 UI와 같은 외부가 변경되더라도 domain layer의 코드는 변경되어서는 안되며, 기획에 의해 비즈니스 로직이 수정되어야 하는 상황일 때 외에는 변경이 되면 안된다.
• UI나 서버를 고려하지 않고, 비즈니스 로직에만 집중되어야 하며, Android에 의존적이지 않은 순수 kotlin 플랫폼 코드이어야 한다.
• 의미 있는 이름을 사용해야 하는데 Entity와 UseCase 클래스, 함수, 변수 명이 해당 기능을 직관적으로 표현하고 있는지 검토하여, 코드 이해도를 높일 수 있도록 한다. 어떻게 보면 기획자가 해당 Domain layer 를 보았을 때 어떤 역할을 하고 있는지 이해할 수 있는 이름이라고 생각하면 된다.
  • 예시: GetUserDetailsUseCase, SubmitOrderUseCase