ENTITY의 식별성을 관리하는 일은 매우 중요하지만 그 밖의 객체에 식별성을 추가한다면 시스템의 성능이 저하되고, 분석 작업이 별도로 필요하며, 모든 객체를 동일한 것으로 보이게 해서 모델이 혼란스러워질 수 있다.
소프트웨어 설계는 복잡성과의 끊임없는 전투다. 그러므로 우리는 특별하게 다뤄야 할 부분과 그렇지 않은 부분을 구분해야 한다.
개념적 식별성을 갖지 않으면서 도메인의 서술적 측면을 나타내는 객체를 VALUE OBJECT라 한다.
어느 것인지에 대해서느 관심이 없고 오직 해당 요소가 무엇인지에 대해서만 관심이 있다.
우편 주문 회사에서 사용하는 소프트웨어에서는 신용카드를 확인하고 물건을 보낼 주소가 필요하다. 하지만 룸메이트도 같은 회사에 물건을 주문하더라도 두 사람이 같은 곳에 있다는 사실이 중요하지 않다. 이 경우 주소는 VALUE OBJECT다.
우편 서비스에 사용하는 소프트웨어에서는 배송 경로를 조직화하기 위해 그 나라를 지역, 도시, 우편 구역, 블록, 개별 주소로 끝나는 계층구조 형태로 만들 수도 있다. 이 같은 주소 객체는 계층구조상 부모로부터 우편번호를 도출해 낼 수 있는데, 만약 우편 서비스에서 배달 구역을 재할당하기로 했다면 거기에 속하는 모든 주소는 부모 계층의 주소를 따라 바뀔 것이다. 이 경우 주소는 ENTITY다.
전기 설비 회사에서 사용하는 소프트웨어의 경우 주소는 전선 및 전기 공급의 목적지에 해당한다. 룸메이트가 각자 전기 점검을 요청한다면 전기 설비 회사에서는 점검 목적지를 파악할 필요가 있다. 이 경우 주소는 ENTITY다. 아니면 모델에서 주소 속성이 포함된 ENTITY인 '거주지'와 설비 점검을 연관시킬 수도 있다. 이렇게 되면 주소는 VALUE OBJECT일 것이다.
VALUE OBJECT는 많아지는 경향이 있으므로 성능 최적화를 위한 별도의 대안을 마려하는 것이 중요
복사와 공유 중 어느 것이 경제성 면에서 더 나은지는 구현 환경에 따라 달라진다. 복사의 경우 객체의 개수가 굉장히 많아져 시스템이 무거워질 수도 있지만 공유 또한 분산 시스템에서는 느려질 수도 있다.
분산 시스템에서는 다른 서버에 위치한 VALUE OBJECT의 참조를 갖고 있을 경우 메시지에 대한 응답이 느려질 것이므로 대신 객체 전체의 사본을 다른 서버로 전달
한 객체가 다른 여러 객체에서 참조되고 있다면 그러한 객체 가운데 일부는 가까이(동일한 페이지상에)에 위치하지 않을 것이므로 데이터를 가져오는 데 물리적인 연산이 추가적으로 필요
동일한 인스턴스에 대한 객체 참조를 공유하기보다는 해당 인스턴스의 사본을 만드는 식으로 여러 ENTITY의 속성 역할을 하는 VALUE OBJECT는 각 ENTITY가 사용하고 있는 것과 같은 페이지에 저장할 수 있음(역정규화)
역정규화를 통해서, 저장 공간이나 유지보수의 단순함보다는 접근 시간이 더 중요한 경우에 종종 사용되곤 함