개별 엔터티로 설계해야 하는 코드

엔터티의 하나의 인스턴스가 개별 개체를 의미하지 않고 개별 개체를 묶은 개념이더라도 명(名) 외의 다른 속성도 관리해야 한다면, 코드 속성으로 설계하지 않고 개별 엔터티로 설계한다. 즉 개별 개체를 묶은 개념이라도 고유 속성이 필요하다면 엔터티로 설계한다.

 

만약 종합카드/체크카드/신용카드/신탁통장 등 거래 매체의 유형을 관리한다면, 데이터가 개별 개체가 아니라 묶은 개념인 유형을 의미하므로 코드 속성으로 설계해야 한다. 하지만 재발급기간, 발급가능고객종류 등과 같이 매체 유형에 따라 관리해야 할 속성이 존재한다면 [그림 거래매체유형] 거래매체유형 엔터티처럼 별도의 엔터티로 설계한다.

 

[그림 거래매체유형]

 

해당 매체 유형의 재발급 기간을 관리해야 한다면 속성이 필요한 것이어서 위와 같이 엔터티로 설계할 수 밖에 없다.

 

설계 당시에는 관리할 속성이 명(名) 밖에는 없지만 향후 추가될 가능성이 있을 때도 엔터티로 설계해서 확장 가능하도록 해야 한다. 추가될 가능성이 있는데도 엔터티로 설계하지 않고 코드 속성으로 설계하면 나중에 수정하기 매우 어렵게 된다.

 

비록 하나의 코드 유형에서만 관리된다고 해도 추가해야 할 속성이 일반적인 의미를 나타내는 속성이라면 코드 속성으로 설계해서 코드를 관리하는 엔터티에 필요한 속성을 추가할 수 있다.

 

예를 들어 추가해야 할 속성이 정렬 순서를 의미한다면 이는 다른 코드 유형에도 적용될 수 있는 일반적인 속성이라 코드 엔터티에 추가해도 부작용이 줄어든다. 아래와 같이 일반적인 속성인 정렬순서 속성을 모든 코드를 관리하는 통합코드 엔터티에 추가할 수 있다.

 

[그림 코드엔터티정렬순서]

 

1~2개의 코드유형에 대해서만 정렬순서 속성에 값을 관리하고 나머지 코드유형에는 정렬순서 속성 값을 관리하지 않아 널(Null)이 되더라도 정렬순서 속성은 어느 코드 유형에든 관리할 수 있는 일반적인 속성이라 부작용이 적다.

 

하지만 위와 같이 모든 코드에 적용 가능한 일반적인 속성은 매우 드물다. 코드유형에 따라 고유한 속성이 대부분이다. 어떠한 고유한 속성이라도 한번 허용하면 지속적으로 늘어날 수 있다는 것에 주의해야 한다.