제목

근거가 있는 트레이드 오프를 하자. feat. Entity 와 식별자.

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

개발 툴

대상자

• 백엔드 개발자, DDD(도메인 주도 설계) 실무자
• 난이도: 중급 이상 (DDD 개념 이해와 설계 패턴 적용 능력이 필요)

핵심 요약

• Entity의 식별자(id)는 nullable 하게 설계하는 것이 유지보수 및 설계 유연성에 유리하다.
• 식별자(nullable) 관리의 책임은 저장 계층(Repository)에 위임하는 것이 시스템의 안정성과 인덱싱 효율성을 보장한다.
• Entity의 불변식 검증은 인스턴스 생성 시 수행되어야 하며, 이는 식별자(nullable)의 유연성과 별도로 처리 가능하다.

섹션별 세부 요약

1. 식별자 nullable 설계의 배경

• 기존 코드 기반: 백엔드 Entity의 id는 대부분 nullable 하게 설계되어 있었음.
• Repository 책임 명시: id 생성은 Repository에 위임하여, 영속성과 인덱싱 이점을 활용.
• Auto-Increment 전략의 관성: 기존 설계에 대한 편리성과 습관적인 선택으로 nullable 설계 지속.

2. DDD 리뷰를 통한 설계 재검토

• 리뷰 요청의 의미: DDD 전문 동료의 피드백을 통해 설계의 명확성과 이점 재검토 필요성 인식.
• Entity 식별자 nullable의 문제점:

- nullable 식별자 관리의 복잡성 증가.

- Entity의 존재성과 식별자 유일성 간 갈등 가능성.

• 식별자 non-null로 변경 시도:

- Entity의 식별자 유일성 강조.

- Repository의 인덱싱 이점 활용.

3. 트레이드 오프 분석 및 결론

• 이득 (non-null 식별자):

- Entity의 식별자 의미 명확화.

- Repository의 인덱싱 이점 활용 가능.

• 손해 (non-null 식별자):

- Entity 생성 시 불변식 검증 책임 이양.

- DB 인덱싱 이점 포기.

• 이득 (nullable 식별자):

- Entity 생성 시 불변식 검증 가능.

- 저장 계층의 인덱싱 이점 유지.

• 결론: nullable 식별자 설계 유지.

- "코드 변경 없이 설계의 근거와 트레이드오프를 명확히 인지하는 것이 더 중요한 변화"

결론

• "코드 변경 없이도 설계의 근거와 트레이드오프를 명확히 정의하는 것이 실무에서의 핵심"
• Entity의 식별자(nullable) 관리와 불변식 검증은 별도로 설계할 수 있으며, 이는 저장 계층과 Entity의 역할 분리에 기반함.
• DDD 개발자는 설계 선택의 근거를 명확히 정의하고, 동료와의 협의를 통해 트레이드오프를 반복적으로 검토해야 함.