이 기능이 왜 필요한지에 대한 내용을 스스로에게 한번 물어보고 시작해보자.
우리가 팬미팅을 진행하는데 있어 해당 필요한 것이 바로 화상 채팅방을 생성하는 것이다. 이 화상 채팅방은 단순히 사용자가 방 생성하기를 클릭해서 누르는 것이 아니다. “자동으로” 판매된 티켓의 수량을 기반으로 팬미팅에 필요한 화상채팅방을 생성하는 것이다. 그렇기에 스케줄링 기능이 필요하게 되었다.
‘새로운 아티스트 UI를 만들어 버튼을 누르는 방식도 있다.’ 어떤게 리소스가 더 많이 들어갈지 생각해봐야 한다. UI를 만드는데 사용되는 리소스 + 프론트 UI 개발 + 백엔드 기능 개발 vs 스케줄링 기능 + 백엔드 기능 개발 둘중 하나를 생각한다면 현재 개발한다고 쳤을 때 리소스가 더 적게 들어가는 것은 후자인 것 같다. 따라서 스케줄링으로 해보자.
이 기능을 구현하기 위해서는 어떻게 해야하는지 생각해보자.
팬미팅 방을 생성하는 크론잡을 생성함에 있어 방식이 2가지가 있다.
1번 방식은 티켓 판매를 생성했을 때 팬미팅 시작 날짜도 정하기 때문에 그 정보를 기반으로 바로 코드 상에서 크론 잡을 등록한다는 장점이 있다. 그러나 단점은 티켓 판매를 취소하거나 또한 팬미팅 날짜와 시간을 변경할 때에도 크론 잡에 등록한 것을 삭제하고 새로 생성하거나 내용을 변경하는 로직이 동시에 들어가야 한다. 이렇게 기능을 짜게 될 경우 스케줄이라는 기능과 팬미팅이라는 기능이 너무 크게 강결합될 우려가 존재한다.
2번 방식은 매일 밤 12시에 크론잡을 등록하는 로직을 초기에 등록해놓고 매일 다른 크론잡을 실행하도록 하는 것이다. 여기서 당일에 팬미팅 시간 변경을 금지해놓아 변경을 사전에 차단할 수 있다. 또한, 팬미팅 도메인과 스케줄 도메인이 적절히 분리되어 스케줄 도메인에서는 팬미팅 기능을 불러와 등록하는 방식으로 코드 상 로직도 복잡하지 않게 될 수 있다. 추후 리팩토링이 편해질 수 있다. 정리하면 아래와 같다.
그렇다면 구체적으로 구현해야하는 기능들을 생각해보고 정리해보자.
여기서 스케줄 도메인과 팬미팅 도메인을 각각 생각해보자.