VALUE_OBJECT

ENTITY 의 식별성을 관리하는 일은 매우 중요하지만 그 밖의 객체에 식별성을 추가한다면 시스템의 성능이 저하되고, 분석 작업이 별도로 필요하며, 모든 객체를 동일한것으로 보이게해서 모델이 혼란스러워질 수 있다. 소프트웨어 설계는 복잡성과 끊임없는 전투다. 그러므로 우리는 특별하게 다뤄야 할 부분과 그렇지 않은 부분을 구분해야 한다. 하지만 이러한 범주에 속하는 객체를 단순히 식별성이 없는 것으로만 생각하면다면 우리의 도구상자나 어휘에 추가할게 그리 많지 않을것이다. 사실 이 같은 객체는 자체적인 특징을 비롯해 모델이 중요한 의미를 지닌다. 이것들이 바로 사물을 서술하는 객체다.

개념적 식별성을 갖지 않으면서 도메인의 서술적 측면을 나타내는 객체를 VALUE_OBJECT 라 한다. VALUE_OBJECT 는 설계 요소를 표현할 목적으로 인스턴스화 되는데, 우리는 이러한 설꼐 요소가 어느것인지에 대해서는 관심없고 오직 해당요소가 무엇인지에 대해서만 관심이 있다.

모델에 포함된 어떤 요소의 속성에만 관심이 있다면 그것을 VALUE_OBJECT 로 분류하라. VALUE_OBJECT 에서 해당 VALUE_OBJECT 가 전하는 속성의 의미를 표현하게 하고 관련 기능을 부여하라. 또한 VALUE_OBJECT 는 불변적(immutable)으로 다뤄라. VALUE_OBJECT 에는 아무런 식별성도 부여하지 말고 ENTITY 를 유지하는데 필요한 설계상의 복잡성을 피하라.

VALUE_OBJECT 의 설계

VALUE_OBJECT 는 많아지는 경향이 있으므로 성능 최적화를 위한 별도의 대안을 마련하는 것이 중요할 수 있다. 복사와 공유 중 어느 것이 경제성 면에서 더 나은지 구현환경에 따라 달라진다. 복사의 경우 객체의 개수가 굉장히 많아져 시스템이 무거워질 수도 있지만, 공유 또한 분산시스템에서는 느려질 수 있다.

공유의 제한(공유는 다음과 같은 경우 가장 도움이 되고 문제가 적게 일어난다.)

  1. 공간을 절약하거나 데이터베이스 내의 객체 수를 줄이는 것이 중요한 경우
  2. 통신 부하가 낮은 경우(이를테면, 중앙집중형 서버)
  3. 공유 객체의 불변성이 엄격하게 지켜지는 경우
특별한 경우 : 변경가능성을 허용하는 경우

- VALUE 가 자주 변경되는 경우
- 객체 생성이나 삭제에 비용이 많이 드는 경우
- 교체(변경이 아닌)로 인해 클러스터링이 제한되는 경우
- VALUE 를 공유할 일이 그리 많지 않거나 클러스터링을 향상시키기 위해서나 다른 기술적인 이유로 공유가 보류된 경우

중요한것은, Value 의 구현이 변경 가능하다면 그것을 공유해서는 안된다.
Value 의 공유 여부와는 관계 없이 VALUE_OBJECT 는 가급적 변하지 않게 설계한다.