DDD. ORM과 투명한 영속성 2부

REFERENCE OBJECT의 별칭(aliasing) - ENTITY

 

 

• REFERENCE OBJECT는 시스템 내에 유일하게 존재하고 상태를 추적할 수 있는 도메인 객체를 의미한다. 
• REFERENCE OBJECT는 유일성 및 추적성을 만족시키기 위해 식별자(identity)를 가지며 동일한 객체를 다른 이름으로 참조할 수 있도록 별칭(aliasing)을 허용한다. 
• 별칭은 여러가지 골치 아픈 문제를 야기하지만 그와 동시에 시스템의 모든 부분이 REFERENCE OBJECT의 상태를 공유할 수 있도록 함으로써 도메인의 무결성을 유지하도록 한다.

 

 

• REFERENCE OBJECT의 동일함(identical)을 테스트하기 위해 ‘==’ 연산자를 사용하여 식별자를 비교할 수 있다.
• ‘==’ 연산자는 객체 생성 시에 자동으로 부여되는 식별자를 비교하며 대개의 경우 객체가 위치하고 있는 메모리 주소를 사용한다. 두 객체의 메모리 주소가 다르면 두 객체는 다른 것으로 판단된다.

 

 

 

• REFERENCE OBJECT는 도메인 객체의 서로 다른 두 가지 측면을 설명하기 위해 사용된다. 
• 첫번째는 REFERENCE OBJECT의 의미론적인 측면이다. 
• 도메인 개념의 유일성과 추적성은 REFERENCE OBJECT의 필요조건이다.
• REFERENCE OBJECT의 의미론적인 특성은 REPOSITORY, AGGRGATE와 같은 다른 도메인 요소에 영향을 미친다. 
• 의미론적인 측면 배후에는 REFERENCE OBJECT의 기술론적인 측면이 존재한다. REFERENCE OBJECT는 생성 시 메모리 주소를 기반으로 한 식별자를 할당 받으며 “==” 연산자의 경우 식별자를 사용해서 객체의 동일성을 판단한다는 것을 가정한다.

 

 

• 만약 어떤 자료에서 REFERENCE OBJECT라는 용어를 발견했다면 의미론과 기술론 중 어떤 측면을 다루고 있는 지를 먼저 파악해야 한다. 
• 대부분의 경우 이런 구분이 명확하지만 어떤 경우에는 오해의 소지가 있을 수 있으며 때때로 이런 오해가 REFERENCE OBJECT의 의미론적 측면을 이해하는데 방해 요소로 작용하기도 한다. 
• 문제는 REFERENCE OBJECT의 의미론과 기술론이 충돌하는 영역이 존재한다는 점이다. 의미론은 도메인의 특성이다. 기술론은 언어 자체의 특성이다.

 

 

 

• 의미론이 도메인의 본질적인(essential) 특성이라면 기술론은 비본질적인(accidential) 특성이다. 
• 본질적인 특성은 변하지 않는 반면 비본질적인 특성은 언어, 환경, 기술에 따라 영향을 받을 수 있다.
• 소프트웨어 개발의 복잡성은 본질적인 특성에 기인한 것이지 비본질적인 특성에 기인한 것이 아니다. 
• 그러므로 소프트웨어 문제의 본질을 다루는 도전, 즉 복잡한 개념적 구조를 체계화하는 것을 우선적으로 고려해야 한다.

 

 

 

• 따라서 도메인의 본질적인 특성을 강조하고 기술에 종속된 비본질적인 개념을 감추기 위해 REFERENCE OBJECT를 대체할 수 있는 용어가 필요하다. 
• 우리는 REFERENCE OBJECT의 기술적인 측면을 캡슐화하고 도메인 측면만을 추상화하기 위해 ENTITY라는 용어를 사용한다. 
• 일반적으로 REFERENCE OBJECT라는 용어가 도메인의 구현을 객체 지향 언어라는 틀로 한정짓는데 비해 ENTITY라는 용어는 광범위한 구현 기술을 수용할 수 있도록 한다.

 

 

 

• ENTITY의 개념은 REFERENCE OBJECT와 동일하다. 
• ENTITY는 식별자(identity)를 가지고 추적가능하며 연속성을 가지는 도메인 개념이다.
• ENTITY는 속성이 아닌 식별자로 구분된다. 
• 반면 VALUE OBJECT는 식별자가 아닌 속성으로 구별되고 일반적으로 VALUE OBJECT의 생명주기는 ENTITY에 종속된다.

 

 

• ENTITY는 도메인 내에 존재하는 개념의 연속성을 강조한다. 
• 따라서 ENTITY라는 용어는 단순히 시스템 내에 존재하는 객체만을 지칭하지 않는다.
•  ENTITY는 표현 매체의 특성이나 기술에 독립적이다.

 

 

• 고객의 신규 가입을 처리하기 위해 시스템은 고객 정보를 상태로 가지는 객체를 생성한다. 
• 생성된 고객 객체는 비즈니스 로직을 처리하기 위해 사용된 후 영구 저장소에 보관된다. 
• 대부분의 경우 영구 저장소로 관계형 데이터베이스를 사용할 것이며 고객 객체는 데이터베이스 테이블의 한 레코드로 저장될 것이다. 

 

 

• 시스템은 다시 고객 정보가 필요한 경우 데이터베이스로부터 레코드를 읽어 고객 객체의 상태를 복원하고 비즈니스 로직을 처리한 후 변경된 상태를 다시 데이터베이스에 저장한다. 
• 시스템은 주기적으로 고객 정보를 공유하는 제3의 시스템에 해당 고객 정보를 전송해야 할 수도 있다. 
• 시스템은 고객 정보를 바이트 스트림으로 변경한 후 네트워크를 통해 다른 시스템에 전송한다. 
• 고객 정보를 수신한 시스템은 다시 바이트 스트림을 고객 객체로 복원하고 비즈니스 로직을 처리한 후 적합한 데이터베이스에 저장한다.

 

 

• 위 예에서 신규 가입 고객의 정보는 객체, 데이터베이스 레코드, 네트워크 전송을 위한 바이트 스트림, 타 시스템 내의 객체, 타 시스템 내의 데이터베이스 레코드와 같이 다양한 형태로 변경된다.
• 그러나 이들 형태와 무관하게 이들은 한가지 동일한 속성을 공유한다. 즉, 도메인 내에 존재하는 동일한 고객의 상태를 표현한다는 것이다. 이것이 ENTITY의 본질이다.

 

 

• ENTITY는 도메인 객체의 표현 형태를 초월해서 동일한 도메인 개념의 추적성과 유일성을 강조한다. 
• ENTITY라는 용어를 사용함으로써 메모리 상의 고객 객체와 데이터베이스에 저장된 고객 테이블의 레코드를 동일한 대상으로 바라볼 수 있다. 
• 고객 객체는 언젠가는 가비지 켈렉터에 의해 소멸되겠지만 고객 그 자체는 데이터베이스를 통해 연속적인 추적성을 가진다. 

 

 

 

• ENTITY라는 용어는 도메인 개념의 연속성과 생명 주기를 구현 기술에 독립적인 문맥 상에서 이해할 수 있도록 한다.
•  이것이 자칫 도메인 객체의 생명주기를 객체 자체의 생명주기와 혼동하도록 할 여지가 있는 REFERENCE OBJECT라는 용어를 사용하지 않음으로써 얻게 되는 궁극적인 효과라고 생각한다.
•  ENTITY가 REFERENCE OBJECT를 표현 형태와 기술에 독립적인 개념으로 확장한다면 REFERENCE OBJECT의 생명 주기와 식별자의 의미는 어떻게 될 것인가? 이것 역시 미묘하지만 적지 않은 변화를 수반한다.

 

 

 

참조

---

이터니티 - Domain-Driven Design의 적용