2. 객체의 종류

객체의 종류 중에서 유명한 VO, DTO, DAO, Entity에 관해 함께 살펴보죠. 

 

2.1 VO(Value Object: 값 객체)

VO라는 것은 대체 무슨 의미일까요? VO라는 것은 클래스로 만들어진 객체를 값(value)과 같이 볼 수 있다는 의미입니다. 해당 클래스는 객체지만 동시에 값입니다. 그래서 값 객체라고 부릅니다. 그럼 값은 뭘까요?

 

값의 사전적 정의가 중요한 것이 아니죠. 값이라고 부르는 것의 특징 와 이것이 '소프트웨어 관점에서 어떻게 해석되는가'입니다. 이 특징을 파악한다면 이 특징들을 만족하는 객체를 만들어 그 객체를 '값 객체'라고 부를 수 있을 것입니다.

 

소프트웨어 설계자 입장에서 값은 불변성, 동등성, 자가 검증이라는 특징이 있습니다. 이제 해당 특징에 대해 설명할 것이고, '객체를 값으로 만들려면 이러한 특징들이 필요하다'라고 생각해 주시면 좋습니다.

 

 

2.1.1 불변성

불변성(immutability)이란 말 그대로 '변하지 않는다'라는 의미입니다. 값은 변하지 않습니다. 이 간단한 개념은 시스템의 복잡도를 획기적으로 낮출 수 있는 개념이라서 소프트웨어 설계에서 정말 중요한 개념입니다. 이 불변성이라는 특징 덕분에 소프트웨어 중 일부를 예측할 수 있고, 신뢰할 수 있게 만들 수 있기 때문입니다.

 

소프트웨어는 불확실성으로 가득한 복잡계입니다. 소프트웨어는 불확실한 요소가 너무 많으므로 믿을 수 있고, 확실한 영역으로 최대한 많이 만들어내는 것이 중요합니다. 그리고 여기서 믿을 수 있는 코드란 항상 변하지 않고 똑같은 결고 와 똑같은 값만 돌려주는 코드를 말하죠.

 

다시 불변성이라는 개념에 집중해서 생각해보죠. 불변성은 '변하지 않는' 특성이라고 했습니다. 자바에서는 어떻게 구현할 수 있나요? 변수 값을 변하지 않게 하고 싶을 때 사용하는 final입니다. VO는 불변성이라는 특징을 갖고 있는 객체를 말하며, VO는 불변이어야 합니다. 객체가 생성된 이후 거기에 내재된 값이 변경돼서는 안 됩니다. 그래서 VO로 선언된 모든 멤버 변수는 불변(final)으로 선언돼 있어야 합니다.

 

그래서 'VO가 무엇이냐'라는 질문에 가장 먼저 나오는 답변으로 '객체가 불변 상태여야 한다'라는 답변입니다. 하지만 '모든 멤버 변수가 final로 선언돼 있으면 VO다'라는 답변은 틀린 설명이 됩니다. 왜냐하면 final로 선언하더라도 원시 타입이 아닌 참조 타입인 객체가 있다면 불변성이 보장되지 않을 수 있기 때문입니다.

 

또한 불변성은 변수에만 적용되는 개념이 아닙니다. 함수에도 적용될 수 있으며, 이를 순수 함수라고 부릅니다. 그래서 멤버 변수와 마찬가지로 VO안의 모든 함수는 순수함수여야 합니다. 불변의 가치는 상속에 의해서도 쉽게 깨질 수 있습니다. 그러므로 VO 클래스는 final 클래스로 선언돼야 합니다. 아예 해당 클래스를 상속하지 못하게 해서 불변성이 유지되게 만드는 것입니다.

 

'객체가 불변이다'라는 것은 단순히 '객체가 갖고 있는 값들이 변하지 않는다'에서 끝나지 않습니다. VO의 불변성이라는 특징을 완벽하게 노력하는 것이 아니라 불변성이 지닌 '가치'를 쫓아야 합니다. 그래서 'VO가 갖고 있는 특징 중 하나인 불변성'이 아니라 '불변성' 자체에 주목해야 합니다. 강조하는 이유는 객체를 신뢰할 수 있게 만들기 위함이죠. 덕분에 다른 객체와 협력하는 과정에서 항상 예측 가능한 방식으로 동작합니다.

 

불변 객체를 사용하면 프로그램의 신뢰성이 높아집니다. 모든 객체와 함수를 불변으로 만들어야 한다는 말이 아닙니다. 불확실성을 제거할 수 있는 부분과 불확실성을 안고 가야 하는 부분을 나누는 것을 시작으로 시스템에서 확실한 부분을 최대한 늘려야 한다는 말이죠. 그것이 바로 불변성이 추구하는 목적입니다.

 

 

2.1.2 동등성

가끔 Class를 보면 equals와 hashCode 메서드를 오버라이딩하고 있습니다. 값이 갖고 있는 동등성(equality)이라는 가치 때문입니다. 어떤 객체가 값이고, 상태가 모두 같다면 같은 객체로 봐야 합니다. 따라서 VO를 만들기 위해 자바에서는 equals나 hashCode를 오버라이딩 할 필요가 있습니다. 오버라이딩하지 않는다면 equals와 hashCode 메서드는 객체의 참조값, 즉 메모리상의 주솟값을 이용해 비교하죠. 이는 VO의 설계 의도와 일치하지 않습니다. 그래서 equals와 hashCode 메서드를 오버라이딩해서 상태를 비교하는 코드로 바꿔야 합니다.

 

아쉽게도 많은 프로젝트에서 VO를 만들려고 노력하지만, 'VO는 동등성을 지켜야 한다'라는 가치는 반영하지 않는 경우가 많습니다. 괜찮은 방법으로 롬복의 @Value 애너테이션을 사용해 보는 것입니다. 이는 값 객체를 만들 때 유용하게 활용할 수 있습니다. 이 애너테이션은

 

1. equals, hashCode 메서드가 객체의 상태에 따라 비교하는 메서드로 자동 생성됩니다.

2. 멤버 변수가 final로 선언됩니다.

3. 클래스가 final로 선언됩니다.

 

참고로 조금 더 알아보죠. VO의 또 다른 특징으로 'VO에는 식별자를 넣어서는 안 된다'라는 특징입니다. 즉, id 같은 식별자 필드를 멤버 변수로 갖고 있어서는 안 되죠. 왜냐하면 '식별자의 정의'와 'VO의 동등성 개념'이 서로 충돌하기 때문입니다. 식별자가 존재하는 순간 이 객체에 존재하지 않았던 예측 불가능성이 다시 생깁니다. 이는 VO로 적합하지 않은 객체를 VO로 만들려 했기 때문이며, 동등성과 식별자는 의미상 충돌이 생길 수밖에 없기에 식별자를 갖는 객체는 VO가 될 수 없습니다.

 

 

2.1.3 자가 검증

자가 검증이란(self Validation)이란 말 그대로 클래스 스스로 상태가 유효한지 검증할 수 있음을 의미합니다. 즉 '유요 하지 않은 상태의 객체가 만들어질 수 없다는 것'을 의미합니다. VO의 생성자에는 반드시 유효한 상태 값이 들어오는지 검증하는 코드가 있어야 합니다. VO로 선언한 객체든 아니든, 자가 검증이 완료된 객체는 사용하기가 매우 편리합니다. 

 

결론적으로 VO의 목적은 신뢰할 수 있고, 예측 가능한 객체를 만드는 것입니다. 따라서 자가 검증이라는 특징 역시 VO를 정의하는 데 필요한 조건입니다. 위와 같은 개념을 이해하는 것도 중요하지만 실제로 개발할 때 중요한 것은 '그래서 이 객체가 VO냐 아니냐'가 아닙니다. 더 중요한 것은 VO의 목적을 고민해 보는 과정입니다. 신뢰할 수 있는 객체를 어떻게 만들지, 어떤 값을 불변으로 만들지, 어디까지 값을 보장해야 할지 등을 고민하는 과정이 개발에 더 도움이 됩니다. VO를 추구하기보다, 불변성, 동등성, 자가 검증, 신뢰할 수 있는 객체를 추구하십시오.

 

 

2.2 DTO

DTO를 직역하면 '데이터 전송에 사용되는 객체'를 의미합니다. DTO는 다른 객체나 시스템에 데이터를 구조적으로 만들어 전달하기 위한 객체입니다. 이러한 이유로 DTO는 객체라고 보기에도 애매합니다. 이름에서부터 '이 객체는 데이터 덩어리'라고 어필하기 때문이죠. 오롯이 데이터를 효과적으로 전달하는 데만 집중합니다. 그 밖의 능동적인 역할이나 책임을 갖고 있지 않습니다. 그러므로 데이터를 읽고 쓰는 것 외에 다른 비즈니스 로직이 들어가서는 안됩니다.

 

정리하자면, DTO는 그저 데이터를 하나하나 일일이 나열해서 전달하는 게 불편해서 데이터를 하나로 묶어서 보내려고 만들어진 객체입니다. DTO에 관한 설명은 끝났고, DTO에 관한 오해 3가지를 살펴볼까 합니다. 같이 확인해보죠.

 

2.2.1 DTO는 프로세스, 계층 간 데이터 이동에 사용된다.

DTO에 관한 첫 번째 오해는 프로세스나 계층 간 데이터 이동에만 사용되는 객체로 인식하는 것입니다. 이보다 조금 더 단순한고 범용적인 개념으로 이해하면 좋은데, DTO의 목적은 데이터를 전달하는 것입니다. 어디서든 사용이 가능하고, 어디에서 사용되느냐가 중요하지는 않습니다. 하지만 매개변수가 너무 많아 객체로 한번 감싸는 것은 일반적으로 추천되는 방식이 아닙니다. 메서드에 필요한 매개변수가 무엇인지에 관한 의존성을 감추기 때문입니다.

 

 

2.2.2 DTO는 Getter, Setter를 갖고 있다.

DTO에 관한 두 번째 오해는 DTO가 반드시 getter, setter를 갖고 있어야 한다고 생각하는 것입니다. 데이터를 읽고 쓰기 위해 필요하다고 생각하는 것 때문인데, getter와 setter는 내부 데이터를 전달하기 위한 방법 중 하나입니다. 이가 없어도 멤버 변수를 public으로 선언하면 됩니다. 하지만 자바에 익숙한 개발자는 '모든 멤버 변수는 private으로 선언돼 있어야 한다'라는 규칙을 관행적으로 따르기 때문이죠. 이는 객체지향이 추구하는 캡슐화의 가치를 지키기 위해 사용됩니다. 즉, 어떤 객체의 속성값을 모두 감춤으로써 직접 접근을 막고 메서드를 통한 간접 접근으로 안정성과 유연성을 확보하려는 것입니다. 

 

그렇다고 앞으로 멤버 변수를 public으로 지정하라고 권장하는 것은 아닙니다. 예로 이메일의 주소를 가져올 때, user.getEmail()의 메서드과 user.email로 변수에 직접 접근하는 것은 분명히 다릅니다. email은 속성에 의존하는 것이고, getEmail() 행동에 의존하는 것이기 때문입니다. 캡슐화의 주요 목표 중 하나인 '정보 은닉'을 달성하기 위해서라도 모든 멤버 변수는 private으로 선언하되 일부만 getter를 제공하는 방향으로 가는 것이 유리합니다.

 

 

2.2.3 DTO는 데이터베이스에 데이터를 저장하는 데 사용되는 객체다.

DTO에 관해 널리 퍼져 있는 또 다른 오해는 DTO를 데이터베이스에 데이터를 저장하고 불러오는 데만 사용하는 객체로 알고 있는 것입니다. 아마도 DTO에서 언급하는 '데이터'를 '데이터베이스'의 데이터로 착각하고 있기 때문일 것입니다. 말 그대로 '데이터를 전송하기 위한 객체'인 것이고, API 통신에 사용되는 요청 본문(request body), 응답 본문(response body)을 받는 데 사용되는 객체도 DTO고, 데이터베이스에서 데이터를 불러오고 저장하는 데 사용되는 객체도 DTO입니다. 또한 객체 간에 데이터를 주고받기 위한 목적으로 만들어진 객체도 DTO입니다.

 

@Data 롬복의 대표적인 애너테이션이고, DTO를 정의하는 데 사용할 수 있는 애너테이션입니다. 이 애너테이션을 사용하면 @Getter, @Setter, @ToString, @EqualsAndHashCode 같은 애너테이션이 한 번에 지정되는데, 귀찮은 일을 한 번에 처리하게 돕죠.

 

그런데 일반적으로 @Data 애너테이션은 자연스러운 객체지향 코드를 만드는 데 방해가 됩니다. 왜냐하면 이를 사용하는 순간, '이 객체는 말 그대로 객체가 아니라 그저 데이터 덩어리다'라고 선언하는 것과 같기 때문이죠. 이는 데이터 위주의 사고를 하도록 만들고, 행동 위주의 사고를 추구하는 객체지향과 멀어지는 것입니다.

 

 

2.3 DAO(Data Access Object: 데이터 접근 객체)

DAO는 데이터베이스 접근과 관련된 역할을 지닌 객체를 가리키는 용어입니다. 아래와 같은 역할을 주로 담당합니다.

1. DB와의 연결을 관리

2. DB에 연결해 데이터에 대한 CRUD 연산 수행

3. 보안 취약성을 고려한 쿼리 작성.

 

말 그대로 데이터에 접근하기 위해 만들어진 객체입니다. 스프링 개발자에게 친숙한 Repository와 같은 개념이라 보면 됩니다. DAO가 만들어진 목적은 도메인 로직과 데이터베이스 연결 로직을 분리하기 위해서 입니다. 

 

 

2.4 엔티티(Entity: 개체)

엔티티를 설명하기 앞서 3가지를 소개하겠습니다.

 

 

2.4.1 도메인 엔티티

일단 도메인은 어떤 '비즈니스 영역' 정도로 이해하면 됩니다. 도메인 모델 중 특별한 모델이 있는데, 이를 도메인 엔티티라고 부릅니다. 1) 식별 가능한 식별자를 갖는다. 2) 비즈니스 로직을 갖는다. 즉, 도메인 엔티티는 식별 가능하고, 비즈니스 로직을 갖고 있으며, 조금 특별하게 관리되는 클래스로 만들어진 객체라고 볼 수 있습니다. 소프트웨어 개발의 세계에서 '엔티티를 개발한다'라는 말은 '도메인 엔티티를 만든다' 라는 의미를 갖고 있습니다. '모델링을 한다'라는 말은 '도메인을 모델링한다'라는 뜻이죠. 도메인 모델링의 주산물은 도메인으로 모델입니다. 도메인 모델에는 다양한 객체들이 존재할 수 있고, 여기에는 도메인 엔티티가 포함될 수 있습니다.

2.4.2 DB 엔티티

데이터베이스 분야에서 개체 또는 엔티티라고 하는 것은 데이터베이스에 표현하려고 하는 유형, 무형의 객체로써 서로 구별되는 것을 뜻한다.

2.4.3 JPA 엔티티