멀티 모듈에서 Mapper는 왜 필요한가

클린 아키텍처, 멀티 모듈에 대해 공부해보면 Mapper라는 요소가 사용된다는 것을 알 수 있다. 그런데 Mapper의 사용 방법에 대해 알아 보면 한가지 의문이 드는 점이 있다.

class ArticleResponseMapper @Inject constructor(): Mapper<ArticleResponseDto, ArticleResponseVo> {
    override fun dtoToVo(dto: ArticleResponseDto): ArticleResponseVo {
        return ArticleResponseVo(
            id = dto.id,
            title = dto.title,
            content = dto.content,
            createdAt = dto.createdAt,
            updatedAt = dto.updatedAt
        )
    }
}

위 코드처럼 매핑하는 두개의 data class가 완전히 동일한 멤버 변수를 가지고 있다는 것이다. 멀티 모듈을 공부하며 여러 깃허브 Repository를 참고했지만 대부분 매핑하는 두 클래스의 멤버 변수는 동일했다.
그렇다면 왜 Mapper를 통해 변환하는 작업을 하는 것일까? 두 클래스의 멤버 변수가 동일하다면 하나를 공유해서 사용해도 되지 않을까?

1. 모듈 사이의 경계 설정

멀티 모듈을 사용하여 얻고자 하는 것은 모듈 간의 의존성을 줄이는 것이다. 서버 통신의 결과로 사용되는 data class는 data 모듈의 책임을 가지고 있는 것이고 비즈니스 로직에 활용하는 data class는 domain 모듈의 책임을 가지는 것이다. 즉, 각각의 모듈에서 사용하는 data class는 해당 모듈의 책임을 반영해야 한다.
서버 통신의 결과를 저장하는 data class를 다른 모듈에서 그대로 사용한다면 모듈 간의 의존성은 증가하게 되고 data class의 구조가 변경되었을 때 영향을 받는 모듈의 개수도 증가하게 된다. 이는 유지보수 측면에서 치명적인 문제이므로 data class를 분리하여 모듈 간 경계를 유지하는 것이 중요하다.

2. 확장성과 유지보수성

Mapper를 활용하여 명시적으로 두 클래스를 매핑한다면 추가적인 데이터 변환 로직을 구현하는 것이 가능하다. 예를 들어, 서버에서 반환하는 리스트 중 일부분만 사용하거나 날짜 데이터의 형식이 실제 사용하는 것과 다르다면 이를 매핑하는 과정에서 데이터 형식을 변환하는 것이 가능하다.
데이터의 흐름이 명확하기 때문에 디버깅 과정에서도 도움이 되고 프로젝트의 규모가 커졌을 때도 관리하기 편하다

3. 유연한 대응

서버에서 반환된 값을 그대로 앱 내부 로직에 사용하면, 서버 데이터에 변화가 생길 때 앱 내부 로직도 수정해야 하는 상황이 발생할 수 있다. 그러나 비즈니스 로직에서 사용하는 data class와 서버 반환 데이터를 저장하는 data class를 분리해두면, 서버 데이터가 변경되더라도 Mapper를 통해 앱 내부 로직을 수정하지 않고도 대응할 수 있다.

4. 데이터 필터링

서버에서 반환하는 값 중에서 사용하지 않는 값이 존재한다면 Mapper에서 이를 필터링하는 것이 가능하다.

결론

위와 같은 이유로 멀티 모듈에서는 모듈 간 의존성을 줄이기 위해 Mapper라는 요소를 추가하여 데이터를 변환하는 작업을 수행한다.