[Next Step 사전과제] 도메인 설계(2) - 도메인 규칙 정의

다음 요구사항을 보고 도메인 구조를 설계해보자!

 

[Use Case]

상영되다

에매하다

좌석을 선택하다

 

[State]

영화 : 영화 제목

상영 : 상영 시간, 상영 길이, 운영 시간, 운영 시간이 겹치는지 확인

예매 : 예매 금액, 여러 영화 한 번에 예매, 결제 수단에 따른 추가 할인(신용카드 5%, 현금 2%), 추가 혜택(무비데이 10%, 시간조건 2,000원)

사용자 : 보유 포인트, 영화와 상영 시간을 고른 뒤 좌석 선택,

좌석 : 행(알파벳), 열(숫자), 등급(s석, a석, b석), 예약여부

 

요구사항을 보고 핵심 유스케이스를 3개 선정하고, 각 객체가 가져야 할 상태와 수행할 도메인 규칙을 정의해봤다.

그러나 이런 방식을 사용하면 데이터 중심 설계로 갈 위험이 있다. 영화는 영화 제목이라는 정보만 가진 '데이터 구조체'가 되는 것이고, 좌석은 행/열정보만 가진 '데이터 구조체'가 될 수 있다. 그리고 로직은 모두 ReservationService같은 절차적 객체 안에 몰리게 된다. 

즉 객체가 아니라 db 테이블과 같은 형태와 유사해진다.

 

다음과 같이 바꾸어봤다.

(초안이라서 가독성이 좋지 않다!!!)

객체들이 메시지를 주고받는 과정에 더 집중한 설계로 바뀌었다.

화살표 마다 쓰여있는 텍스트는 '다른 객체에게 위임할 책임 (전달할 데이터)' 를 의미한다.

 

개선점이 있다면 다음과 같았다.

현재 '영화'객체가 '상영'에게 시간이 겹치냐고 물어보고, '좌석'에게 좌석이 예매 가능하고 물어본 후 '예매'객체가 예매를 하고 있다.

'예매'객체가 영화 예매의 모든 과정을 총괄하는 것처럼 설계하기 위해서였는데, 전혀 그렇게 보이지 않는다.

다시 한 번 수정해보았다.

'상영'이 좌석 예매 가능한지 좌석에게 묻고, 본인이 가진 상영 리스트를 통해 상영 시간이 겹치는지 확인한 후 validate하다고 판단되면 '예매'에게 예매할 책임을 맡긴다.

'예매'는 본인이 가진 예매 정보와 가격 데이터가 있을 것이고, '할인 규칙'에게 최종 할인을 맡긴다.

 

또 다른 설계이다. 예매를 처리할 책임까지 '상영'객체에게 맡기고 '예매'는 예매 정보를 담은 데이터 객체로만 사용하는 것이다.

'상영'객체가 어떤 영화인지, 몇 시에 시작하는지, 어떤 좌석이 있는지에 대한 정보를 전부 알고 있기 때문에 예매할 책임까지 맡겨버린 설계이다. 캡슐화된 느낌이지만 객체 이름과 책임의 조화가 모호하다는 점에서 좋은 설계인지는 모르겠다.

대신 '상영'객체는 예매를 성공시키는 책임에만 집중하게 된다는 관점에서는 응집도가 높은 것 같다.

 

 

아직 실력이 부족하지만, 설계는 코드로 구현하기 위한 단계일 뿐

어떤 설계가 가장 좋은지는 코드로 구현하고 리팩토링을 지속적으로 해보는 경험이 있어야 될 것 같다. 설계만 계속 해서는 실력이 늘지 않을 것 같다..!!