서론

현재 Kotlin과, 그동안 학습하였던 DDD, TDD 등을 실제 코드에 적용시켜 보고자 작은 토이 프로젝트를 진행하고 있다.

진행 도중, 상영관의 좌석에 관한 정보를 담는 Seat 클래스를

DDD 관점에서 Entity로 볼것인가? VO로 볼것인가?

에 대한 고민이 생겨, 사고의 흐름과 결정을 기록으로 남기고자 한다.

Entity, VO

먼저, DDD 관점에서 Entity와 VO는 모두 도메인 모델의 하위 개념이다.

둘 간의 큰 차이점은,

1. Entity는 고유한 식별자를 가지며, VO는 고유한 식별자를 가지지 않는다(이때 주의할 점은, 다음과 같다.)
2. VO는 동일성을 식별자를 통해 따지지 않고, 내부 필드를 통해 따진다.
   1. 따라서, 두 VO의 모든 필드가 같다면, 그 VO는 같은 VO라고 판단한다.

Seat는 무엇일까?

위는 프로젝트 시작전, 간단히 작성한 ERD의 일부이다.

Seat는 상영관 id + 열과 행(column / row)가 같으면 같은 좌석으로 인식되어야 한다

는 점에서 vo라고 생각했다.

이후 좌석 예약 기능을 개발했을 때의 플로우를 다음과 같이 간략하게 생각해 보았다.

1. Cinema Id와 Seat의 column / row 전달받음
2. Seat을 조회하여 (현재 ERD에는 없지만) Seat의 상태 검증
3. '예약 가능' 상태라면, '예약 완료' 상태로 변경 이후 트랜잭션 종료

위 플로우를 생각해 본 이후, Seat의 특징을 나열해 보았다.

1. 상태 변경이 어느정도 잦을 것으로 예상됨(좌석 예약상태변경)
2. 해당 객체를 위한 별도 식별자가 필요(예약시, 식별자를 통해 해당 좌석을 예약.)

이렇게 Seat의 특징을 정리해 보고, 불변적이고 고유 식별자가 필요하지 않은 VO보다는, Entity로써 바라보기로 결정하였다.

동시에 위와 같은 플로우는 DDD관점에서 원칙을 어긴다고 생각이 되었다.

1. Aggregate root인 Cinema를 통하여 상태를 변경하지 않고, 바로 Seat에서 상태 변경(좌석 예약기능 플로우 2,3번)

이부분은 Root Entity인 Cinema를 통하여 Seat의 상태변경을 관리할 예정이다.

결론

1. Seat을 Entity로써 바라보자.
2. Seat이 Entity더라도 상태변경은 항상 Aggregate Root인 Cinema를 통하여 진행하자.