CS 문제 전송 기능 구현, 채널 만들기 이벤트 구현, 프로젝트 구조 리팩토링

[hye-on]

🔗 관련 이슈

resovles: #12 #15

📝 작업 내용

• 새봄봇 초대 시 자동으로 채널을 생성하는 이벤트 구현
• 프로젝트 구조 리팩터링
• 매일 오전 11시에 cs 문제 전송 기능 구현
  
  
  

🍇 고민한 부분

1. listener, handler를 interaction 폴더로 묶은 이유
   이벤트를 감지하고 실행하는 흐름을 하나의 폴더에서 관리하여 응집도를 높이고, 유지보수성을 향상시킴.

2. listener와 handler를 분리한 이유
   listener: 외부 디스코드 이벤트에 의존하는 부분을 분리하여 핸들러를 독립적으로 테스트 가능하게 만듦.

3. 폴더 구조 개선

• domain: 업무 규칙과 관련된 데이터 및 로직을 관리.
  엔티티와 엔티티의 비즈니스 로직을 포함.
  클린 아키텍처 20장: "업무 규칙은 수익을 창출하거나 비용을 줄이는 데 중요한 규칙 또는 절차."
• discord.gateway.ts: 디스코드 메시지 전송 및 이벤트 처리를 담당.

4. ProblemService와 DiscordGateway 간 호출 구조 고민

➡ Scheduler → ProblemService → DiscordGateway

• ProblemService에서 직접 DiscordGateway를 호출하는 것은 좋지 않음.
  • ProblemService는 문제 데이터를 다루는 도메인 서비스
  • 도메인 레이어가 인프라 레이어에 의존하는 구조가 되어, 변경에 취약한 설계임.

➡ Scheduler -> DailyProblemFacade -> (ProblemService, MessageService, DiscordGateway)

• 프로젝트 요구사항에서 메세지 형식이 복잡 하여 (문제 빈칸, 키워드 등등) 메세지 형식을 구성하는 message 모듈이 생길 가능성이 있음.
• 파사드 패턴을 도입하여 추상화: 현재 역할이 크지 않기 때문에 추가적인 계층을 도입하는 것이 보류.
• 향후 기능이 확장되고 역할이 커지면, DailyProblemFacade를 도입하여 역할을 분리하는 것 고려 중.

➡ 채택: Scheduler -> (ProblemService ,DiscordGateway)

🏃‍♀️ NEXT

• Discord Rate Limit 처리 (queue 기반 메시지 전송)
• 단위 테스트 및 통합 테스트 작성 (pr이 너무 켜져서 분리)