Contents
# 시작하며
# G o o d : 용어의 선
# B a d : 용어의 악
# DTO-VO-Entity-Dao
1. Good : DTO-VO-Entity 들은 "왜" 필요할까?
2. Bad : DTO-VO-Entity 와 같은 정의들은 "꼭" 필요한가?
# 결론은
# 시작하며....
최근 멘토링을 진행하며 DTO, VO, Entity , Domain 등의 단어를 정말 많이 사용한 것 같다.
멘토님이 몇번 들으시더니 위 용어들의 정의를 찾아보고 공유해달라고 하셨다.
예리했다.
내가 생각하는 의도가 맞다면 프로젝트 과정에서 꼭 필요한 작업이라고 생각한다.
나는 가족과 회의나 토론을 정~말 많이한다.
그렇게 살다보니 커뮤니케이션 과정에서 공통된 정의를 가지고 있지 않은 용어들과 암묵적인 전제는 독이 될 수 있다는 것을 알고 있다.
멘토님의 요청을 계기로 한번 용어사용의 선과 악, 그리고 "DTO-VO-Entity-Dao" 에 대한 나의 의견을 정리해본다.
# G o o d : 용어의 선
용어가 명확하게 정의되어 있는 경우에
1. 용어는 빠르고 민첩하다.
용어는 한번 불붙으면 정말 빠르게 확산된다.
이렇게 빠르게 확산된 용어로 커뮤니케이션 과정에서
어려운 개념 설명 과정을 생략할 수 있다.
그런 의미에서...
2. 용어는 자동화의 수단이다.
# B a d : 용어의 악
용어가 명확하게 정의되어 있지 않은 경우에
1. 용어는 산만하다.
커뮤니케이션의 결과로 여러가지 버전이 탄생하기 때문이다.
여러 버전의 결과를 가지고 여러 주체가 행동을 취하기 시작하면
2. 용어는 재앙의 씨앗이 될 수도 있다.
# DTO-VO-Entity-Dao
나의 의견을 정리해본다.
1. Good : DTO-VO-Entity 들은 "왜" 필요할까?
데이터를 담은 객체들이 계층을 오고가며 역할과 기능이 달라지는 경우에 필요하다.
객체를 역할과 기능에 따라 다르게 설명하는 대신
용어를 통해 정의로 구분할 수 있게된다.
공통된 정의가 있으니 혼동을 예방하며 설명 시간을 단축한다.
서버 엔지니어 입장에서 예를 들어본다.
서비스 규모와 함게 어플리케이션의 복잡도도 증가한다.
RequestBody에 여러가지 객체가 담겨오기 시작한다.
서버에서는 받은 데이터를 분리하고 나누어 사용하기 시작한다.
비즈니스 로직도 복잡해졌다.
더 이상 클라이언트에서 받는 데이터는 그대로 DB에 꽂힐수 없다.
데이터를 담은 객체가 어플리케이션의 여러 계층을 넘나들며 기능과 역할이 달라지기 시작한다.
같은 단어를 가지고 기능과 역할별로 다르게 설명해야하는 상황이 빈번히 발생한다.
이제 DTO-VO-Entity 라는 개념들이 필요하지 않을까?
2. Bad : DTO-VO-Entity 와 같은 정의들은 "꼭" 필요한가?
나는 그렇지 않다고 생각한다.
오히려 악이 될 수 있다고 생각한다.
적절하지 않은 상황에서 사용할 경우에는 불필요한 혼동을 일으킨다.
그러니 필요하지 않으면 사용을 피하고 DTO-VO-Entity 를 섞어 쓰는 것을 피하자.
대신 최대한 단순하고, 단순해서 모두 같은 의미로 이해하는 단어를 사용하자.
# 결론은
협업하는 과정에서
자신이 많은 양의 용어들을 분출하고 있다면
자신은 어떤 의미로 사용했는지,
옆에서는 어떤 의미로 이해했는지
확인하는 시간을 가져보자.
