DDD - Value Object

- 출처: 도메인 주도 설계 - 에릭 에반스

- Value-Object (VO)

VO는 개념적인 식별성이 없고 사물의 어떤 특징을 묘사하는 객체이다. 

 

예를 들어 어떤 아이가 펜으로 그림을 그리려고 하고 있다고 가정해보자. 만약 똑같은 색과 굵기와 모양의 펜이 2개가 있다면 아이는 어떤 펜을 사용해도 도 크게 개의치 않을것이다.

 

VO는 설계요소가 어느것인지가 아닌 무엇인지에 관심이 있다고 할 수 있다.

---

- "주소"는 VO인가?

VO와 Entity에 관련된 글이나 자료를 보다 보면 자주 떠오르는 유형의 의문점이 있다. VO와 Entity의 차이 혹은 "주소"는 VO일까? 와 같은 유형의 질문이다. 이 질문에 해답역시 앞의 Entity 장에서 살펴본것과 같이 도메인에서 해결하고자 하는 문제에 따라 다르다.

 

전기설비회사 입장에서 "주소"란 결국 전선 및 전기 공급을 하는 목적지라고 이해할 수 있다. 만약 룸메이트와 내가 동시에 "점검"을 요청한다고 가정해보자.  이때 전기설비회사가 해당 "주소"까지 전선 및 전기가 공급되는 여부에만 신경쓴다면 점검 목적지는 어차피 동일하기 때문에 "주소"는 Entity라고 할 수 있다.

 

반면 "점검"이 발생할 때마다 건별로 관리하고있고, 이 "설비점검"과 "주소"를 연관시켜 관리하면 "주소"는 개념적 식별성의 의미를 갖지 않기 때문에 VO가 된다.

 

---

- VO와 Entity의 참조관계

그렇다면 VO와 Entity는 서로 상하관계를 가지는가? VO가 Entity를 포함할까? 아니면 Entity가 VO를 포함할까?

 

우선 VO는 Entity를 참조할 수 있다. 어떤 어플리케이션에서 길을 안내하는 기능이 있다고 가정해보자. 각 도시는 식별성이 있으며, 각 도시간의 도로에도 특정 번호가 부여되어 있어 식별성이 있다면 도시들과 도로들은 Entity 라고할 수 있다. 이때 출발지와 도착지 그리고 두 도시를 잇는 도로로 구성된 경로가 있다면 이 경로라는 VO는 도시와 도로번호인 Entity를 참조 한다고할 수 있다.

 

그리고 Entity도 VO를 참조할 수 있다. 고객이라는 Entity는 주소라는 VO를 속성으로 가질 수 있다.

---

- VO의 조건

VO를 구성할때에는 아래와 같은 사항에 유의하여 설계하도록 한다.

 

• VO는 가능하면 북변(immutable) 이어야 한다. VO가 불변이 아닌 경우는 정말 드물다. 
• VO에는 식별성을 부여하지 말아야 한다.
• VO는 개념적 완전성(Conceptual whole)을 형성해야 한다. 예를 들어 Person 이라는 객채내에서 도, 시군구, 음변동, 우편번호 속성을 가지고 있을 수 있다. 하지만 이를 주소라는 VO로 추출하면 개념적으로 그러한 속성들이 주소라는 의미체계를 갖게 되어 모델링이 더 명확해진다.

---

- VO의 설계

VO는 식별성이 없기 때문에 여러 인스턴스 중 어느 하나를 사용하느냐는 그다지 중요하지 않다. Entity 보다는 신경쓸게 덜할것 같지만 VO를 설계할때에는 복사/공유/불변성에 관한 의사결정을 해야한다.

 

VO는 단순히 어떤 사물의 상태를 나타내는 값이기 때문에 복사해도 무방하다. 이름이 같은 두 Person 객체가 있다면 1번째 Person 객체의 이름을 2번째 Person 객체의 이름에 복사할 수 있다.

 

이름이 같은 두 Person 이라면 이름 객체 인스턴스 하나를 공유해도 무방하다. 하지만 이럴 경우 1번째 Person의 이름이 변경되면 같은 인스턴스 주소를 참조하고 있던 2번째 Person도 이름이 변경된다. 그래서 VO를 안전하게 공유하려면 불변적이어야 한다.

---

- VO의 공유와 불변성

정말 왠만한 경우가 아니라면 VO를 공유해야하는 상황은 거의 오지 않는다. 하지만 언제나 예외는 존재하는법이다.

 

주택설계 S/W를 만들고 있다고 가정해보자. 건물을 설계할 때 콘센트 요소를 추가할때마다 콘센트 객체를 모두 복사하여 객체를 생성하였다. 만약 콘센트 객체의 생성비용이 크다면?

 

이럴 경우 수백개의 콘센트 VO를 복사하는것보다는 공유하는것이 훨씬 효과적이다. 물론 불변성을 잘 지킨다는 가정하에 말이다. 그럼 VO를 복사할지 공유할지에 대한 의사결정을 어떻게 하면 좋을까? VO를 공유할 때는 아래 사항에 대해 생각해본 후 의사결정을 하자.

 

• 공간을 절약하거나 DB내의 객체수를 줄이는것이 중요하다.
• 서버간 VO 공유시 중앙 집중형 서버라서 통신부하가 낮다.
• 공유 객체의 불변성을 잘 지킬 수 있다.