DDD - Entity

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

- 개요

객체는 본질적으로 속성이 아닌 연속성과 식별성으로 정의 된다. 속성은 객체의 생명주기 동안 계속해서 변해간다. 어릴 때의 나와 현재의 나를 비교해보면 키, 친구들 많은 것이 변했으며 심지어는 이름이 변하는 경우도 있다. 하지만 식별성은 지속되는데 어릴 때의 '나'와 지금의 '나'는 동일하다.

 

Entity는 생명주기 동안 형태와 내용은 급격하게 변하지만 연속성은 유지해야 한다. 그리고 이런 Entity를 추적하려면 식별성이 정의되어 있어야 한다.

 

우리가 좌석 예약 시스템을 만든다고 가정해보자. 만약 좌석을 예약하고 발급받은 입장권에 좌석번호가 명시된 경우 좌석번호를 Entity의 식별성으로 사용해야 한다. 반면 어떤 경우에는 단순히 일반석이라고 등급만 표기가 되어있는 입장권을 발부 받는 경우도 있는데 이런 경우 좌석번호를 반드시 식별성으로 정의할 필요는 없다.

---

- Entity 모델링

객체를 모델링할 때 속성에 관해 생각하는것은 인간의 사고방식상 자연스러운 현상이다. 하지만 Entity의 가장 기본적인 책임은 객체의 행위가 명확하고 예측 가능하게 연속성을 확립하는것이다. 속성이나 행위에 집중하기 보다는 Entity의 가장 본질적인 특징인 식별하고 탐색하는 특징만을 정의해야 한다.

 

그 외에 행위와 속성을 검토해서 Entity와 연관관계에 있는 다른 객체로 옮길 수 있다. 이는 다른 Entity가 되거나 다른 Value-Object가 될 수 있다.

 

아래 그림의 왼쪽에서 공학적으로 Customer라는 Entity의 유일한 식별자는 customerId 이다. 하지만 도메인 관점에서 한번 생각해보자. 우리가 동네 마트에서 포인트를 적립하겠다고 하면 마트 점원이 "customerId가 어떻게 되시는데요?"라고 묻지는 않는다. 보통은 사람이 기억하기 쉬운 "이름하고 전화번호 끝자리요"라고 하는 경우가 많다.

 

이름은 동명이인 많다면 완벽하게 어떤 사람은 식별할 수는 없지만 업무상 식별하는데 보조적으로 사용된다면 Entity의 속성이 될 수 있다.  부가적으로 전화번호나 주소 등도 종종 일치여부를 확인하는데 사용된다.

 

 

 

위 그림의 오른쪽은 업무상 주소와 전화번호를 식별확인에 사용된다고 판단하여 Customer Entity로 옮긴것이다. Entity의 속성을 판단할 때 현실세계에서 Entity의 속성은 무조건 이래야 한다라는 접근 보다는 우리 어플리케이션 모델링에서 해당 속성을 해당 객체를 식별하는데 사용하는가라는 기준으로 유연하게 접근하는것이 좋다.

---

- 식별연산 설계

Entity는 식별성을 만들어낼 수 있는 속성이 필수적으로 존재해야 한다. 식별을 위한 속성은 해당 System 에서 유일해야 하는데 시스템이 분산되어 있거나 객체로 저장된 경우라도 마찬가지다. 즉 물리적 주소(ex - 객체 주소)가 아닌 개념적 식별성이 중요하다.