스팀 앱 개발기 #31 - 도메인 모듈에서 정의하는 데이터 클래스들이 DTO 패턴을 따르는 것이 맞는가?

도메인 모듈에서 정의하는 데이터 클래스들이 DTO 패턴을 따르는 것이 맞는지를 오늘 동료에게 물어 보았습니다. 그 분의 답은 이러하였습니다.

아키텍처는 사실 정답이 없어요. 구현하는 사람 나름의 해석인거죠. 다만 클린아키텍처를 가장 잘 설명하는 아래 그림으로 설명을 하는데 이걸 어떻게 해석하냐의 따라 구조가 달라지는거겠죠.

그렇습니다. 아키텍처가 동일해도 이를 해석해서 구현하는 방식은 개발자마다 다를 수 있습니다. 반드시 이렇게 해야만 한다라는 강제적인 답이 있는 것은 아니지요. 어떻게 분석하고 생각하느냐에 따라 코드 결과는 달라질 수 있는 것입니다.

그렇다면 도메인 모듈에서 정의하는 데이터 클래스들이 DTO 패턴을 따르는 것이 맞을까요? 인터넷에서 자료를 좀 더 찾아보았구요. 다음과 같이 결론을 내렸습니다.

내가 내린 결론은?

DTO 패턴은 도메인 모듈보다는 데이터 모듈에 적용하는 것이 맞는 것으로 판단합니다. DTO의 뜻이 Data Transfer Object(자료 전송 객체)이죠. 앱이 읽을 자료는 API 또는 데이터베이스로부터 받아올 수 있습니다. API 또는 데이터베이스가 앱에 내보내는 데이터가 바로 Data Transfer Object인 것입니다. 저도 자료를 찾아보며 고민해보니 그게 맞다고 판단합니다.

동료가 도메인 데이터 클래스가 DTO 패턴을 따른다고 판단한 이유는 그게 presenter(제 프로젝트에서는 dorian-steem-ui 모듈이 이에 해당)로 전달되기 때문인 듯 합니다. 어떻게 보느냐에 따라 그게 맞을 수도 있겠지만, 사람들이 일반적으로 더 따르는 방향이 더 좋지 않을까 합니다.

그렇다면 리팩토링은?

도메인이 아닌 데이터 모듈의 데이터 클래스들이 DTO 패턴을 따라야 한다고 판단했으므로 이에 따라 이 클래스들의 이름을 변경할 것입니다. 도메인의 데이터 클래스들의 이름 또한 바꿔야겠지요? 아래와 같이 적용할 예정입니다.

클래스 이름	As-is	To-be
데이터 모듈의 데이터 클래스들	Entity로 끝남	DTO로 끝남
도메인 모듈의 데이터 클래스들	DTO로 끝남	끝나는 접미사 없음