Eternity's Chit-Chat

aeternum.egloos.com



Domain-Driven Design의 적용-4.ORM과 투명한 영속성 2부 Domain-Driven Design

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) 특성이다. 본질적인 특성은 변하지 않는 반면 비본질적인 특성은 언어, 환경, 기술에 따라 영향을 받을 수 있다. Fredy Brooks의 말 처럼 소프트웨어 개발의 복잡성은 본질적인 특성에 기인한 것이지 비본질적인 특성에 기인한 것이 아니다. 그러므로 소프트웨어 문제의 본질을 다루는 도전, 즉 복잡한 개념적 구조를 체계화하는 것을 우선적으로 고려해야 한다.

 

따라서 도메인의 본질적인 특성을 강조하고 기술에 종속된 비본질적인 개념을 감추기 위해 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라는 용어를 사용하지 않음으로써 얻게 되는 궁극적인 효과라고 생각한다.

 

ENTITYREFERENCE OBJECT를 표현 형태와 기술에 독립적인 개념으로 확장한다면 REFERENCE OBJECT의 생명 주기와 식별자의 의미는 어떻게 될 것인가? 이것 역시 미묘하지만 적지 않은 변화를 수반한다.


핑백

  • Domain-Driven Design | Jongmin Kim's Blog 2014-09-02 01:18:18 #

    ... 009/02/27 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 3부  2009/02/23 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 2부 2009/02/15 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 1부 2009/0 ... more