도메인 객체의 ID부여

들어가기 앞서,

우테코 레벨2를 진행하면서 기존과는 다르게 도메인 객체를 고유하게 식별해야 되는 상황이 생겼고, 이를 해결하기 위해 구분되어야 하는 객체에 id필드가 생기게 됐습니다.

이로 인해, 도메인 객체가 데이터베이스에 종속적인 존재가 된다는 느낌을 받고, 주변 크루들과 이야기 하면서 현재 저의 주관적인 생각을 정리한 글입니다.

다른 의견이나 잘못된 내용이 있으면 언제든 피드백 해주시면 감사하겠습니다 ^.^

결론

우선 결론부터 말하자면 필요하다가 생각합니다. 여러 인스턴스 중 유일하게 하나의 인스턴스를 식별할 필요가 있는 객체라면 식별자가 반드시 있어야된다고 생각합니다. 그 중에서도 인조키를 통한 식별자가 좋다고 생각합니다.

 

그리고, 정말 DB에 종속적이지 않은게 꼭 좋은거라고 생각하지 않습니다. 요즘 느낀 것은 다양한 선택지 중 트레이드 오프를 생각해 근거 있는 선택이라면 괜찮다고 생각합니다. 

DB에 종속적이지 않겠다고, 식별자를 두지 않고 객체를 식별하기 위해 복잡한 로직이 존재한다면 식별자를 둠으로써 복잡성을 줄이는 선택을 할 수 있다고 생각합니다.

필드 간 동등성 비교로 식별?

필드 간 동등성 비교를 통해 유일한 인스턴스를 식별할 수도 있지 않냐는 의견도 있었다. 그러나 이 경우 unique한 필드가 있는 경우만 유효하다고 생각된다. 

만약, 비즈니스 규칙 중 "Member의 email은 중복되어선 안된다."같은 규칙이 존재한다면 email필드의 동등성 비교로 다양한 Member인스턴스 중 email을 통해 Member를 구분할 수 있다.

하지만, 해당 비즈니스 규칙이 영원히 유지될까? 라고 생각해본다면 그렇지 않다고 생각한다. 그렇다면 해당 구조는 변화에 유연하게 대처할 수 없는 구조가 된다.

 

이런 방식으로 인스턴스를 구분하는 것이 자연키를 이용해 구분하는 것이다.

인조키(id)를 통한 객체 구분

위 예제와 달리 자연키가 아닌 인조키를 통해 구분한다면 email대신 아이디가 중복되어선 안된다는 비즈니스 규칙이 수정되더라도 Member를 구분하는 식별자에는 영향이 없다. 여기서 인조키란 말 그대로 인의적으로 생성한 키(식별자)다. 인조키란 흔히, DB의 Autoincrement로 설정하는 값 처럼 객체에 필요한 필드가 아닌 객체의 식별을 위해 생성된 키다.

 

이제, id를 이용해 Member를 식별하고, email 대신 닉네임이 중복되어선 안된다고 요구사항이 바뀌었다고 가정해보면, Member를 식별하는데 아무런 문제가 되지 않는다.

어떤 객체에 id를 부여하나

여러 인스턴스 중 유일하게 하나의 인스턴스를 식별할 필요가 있는 객체에 id부여가 필요하다고 생각한다. 일반적으로, Money라는 객체가 있다고 가정해보자.

우리는 해당 Money객체의 가치(가격)가 중요하지 Money의 일렬번호가 궁금하진 않고, 실제 비즈니스 요구사항 역시 Money의 가격만 중요하다면 해당 Money에는 굳이 식별자를 부여하지 않아도 된다고 생각한다.