도메인 주도 설계 구현
엔터티(entity)
고유 식별자
사용자가 식별자를 제공한다.
사용자가 직접 고유 식별자의 세부사항을 입력할때 몇가지 문제점이 있다.
- 양질의 식별자를 생성하는 일을 사용자에게 의지한다는 점
애플리케이션이 식별자를 생성한다.
고유식별자를 생성하는 식별자 생성패턴
- 고유 식별자 (UUID)
- 전역 고유 식별자 (GUID)
에그리게잇 에서는 UUID로 되지만 에그리게잇 루트로 쓰여지는 엔터티는 GUID가 필요하다.
영속성 메커니즘이 식별자를 생성한다.
고유 식별자의 생성을 영속성 메커니즘에 위임하는 방식만의 이점이 있다.
데이터 베이스로 시컨스나 증가 값을 호출한 결과는 언제나 고유하다.
성능적 측면이 단점이 될수도 있다. 값을 얻기 위해 데이터베이스까지 가야 된다.
순서가 중요할수도 있다.
- 때론 식별자 엔터티의 생성과 할당이 일어나는 시점이 중요하다.
- 빠른 식별자 생성과 할당은 엔터티가 저장되기 전에 일어난다.
- 늦은 식별자 생성과 할당은 엔터티가 저장될때 일어난다.
또 하나의 바운디드 컨텍스트가 식별자를 할당한다.
또 다른 컨텍스트가 실별자를 할당할 땐 각 식별자의 검색과 매칭과 할당을 위한 통합이 필요하다.
이 방법은 식별자 생성 전략 중에서 가장 복잡하다. 이 접근법은 최대한 보수적으로 사용하라.
식별자 생성의 시점이 문제가 될때
식별자 할당받기 전에 새로운 엔티티가 먼저 식별자를 할당 받으면 중복된 식별자를 가질수도 있다.
위 버그를 해결하기 위해서
- 초기에 식별자를 가져와서 할당하거나
- equals 메소드를 활용하여 식별자가 아님 다른값을 활용해야 한다.
대리 식별자
하이버네이트 같은 ORM 도구는 고유의 식별자를 처리하길 원한다.
하이버네이트는 숫자 시퀀스 같은 데이터 베이스 원시 타입을 각 엔터티에 1차 식별자로 사용하는 편을 선호한다.
도메인에서 다른 식별자가 필요하다면 충돌이 일어난다 그래서 두개의 식별자를 선택할수도 있는데
하이버네이트를 위한 식별자를 대리식별자라고 한다.
식별자 안정성
대부분의 경우 고유 식별자는 수정하지 못하도록 보호되고 할당된 엔터티의 수명주기에 걸쳐 안정적으로 유지돼야 한다.
식별자 수정을 방지하는 케이스는 당연히 있다.
- 식별자 세터를 클라이언트로 부터 숨기는 방법
- 엔터티를 보호하기 위해 세터 내에 가드를 만드는 방법