미니 프로젝트 - 알림 생성 기능의 위치

📘알림 메시지를 생성할 때 고려해야 할 포인트들 정리

알림 메시지 생성 위치 고민

• 메시지를 누가, 어디서, 언제 만드는지가 구조와 책임 분리에 영향
• 알림 대상 조회, 메시지 포맷 구성, 전송 트리거 등 단계별로 분리 가능
• 퍼포먼스와 유연성 측면 모두 고려
• 메시지 생성 위치에 따라 테스트 용이성, 유지보수 난이도 변화

---

알림 생성 시 저장되는 메세지 형식 예시

//모임 생성 알림
-> 모임 생성 시 위치 및 관심사 기반 유저에게 알림 생성
"관심 지역에 새로운 {런닝} 모임이 추가되었습니다."

//모임 임박 알림
-> 모임 시작시간이 일정시간(30분, 하루) 뒤에 시작일 경우 참여자 및 관리자에게 알림 생성
"내일 {열심히달리기} 모임이 있습니다"
"30분 뒤에 {열심히달리기} 모임이 있습니다"

//모임 참석 알림
-> 모임 참석 시 모임장에게 알림
"{모모} 님이 모임에 참석했습니다."

---

1. NotificationService 에서 메시지 생성

• 전달받은 userId, meetingId 기반으로 유저 이름, 모임 이름 조회해서 메시지 구성
• 알림 전용 로직 분리
• 알림 대상 필터링과 메시지 구성까지 이곳에서 담당

장점

• 알림 로직 분리되어 책임 명확
• 메시지 포맷 변경 시 이 서비스만 수정 가능

단점

• 이미 조회된 정보를 다시 DB에서 꺼내야 해서 쿼리 중복 발생
• 알림 케이스 많아지면 책임 과중

---

2. MeetingService 에서 메시지 생성

• 서비스 내에서 이미 로딩한 유저, 모임 정보로 메시지 조립
• 알림 트리거는 이벤트로 넘기되, 메시지는 이 시점에서 완성

장점

• 쿼리 중복 없음, 성능 면에서 유리
• 이벤트에 불필요한 정보 생성 X

단점

• 도메인 로직이 알림까지 책임지게 됨 → 관심사 분리 흐려짐
• 메시지 포맷 일관성 관리 어려움

---

3. NotificationEvent 에서 메시지 생성

• 알림 타입별로 이벤트 DTO 정의함 (userId, meetingName 등 포함)
• 메시지는 이벤트 핸들러에서 최종 생성함
• 이벤트 객체에 메시지에 필요한 최소 정보만 담음

장점

• 메시지 생성 책임 분산 → 테스트 편함
• Kafka 등 메시지 브로커 도입 시 구조 변화 최소화 가능
• 도메인 로직에서 알림 책임 분리 가능

단점

• 알림 케이스 늘어나면 이벤트 DTO 클래스 많아짐
• 메시지 템플릿 일관성 유지 위해 추가 전략 필요

---

결론: MeetingService에서 메시지 생성 방식 선택함

쿼리 중복 없이 이미 조회한 정보를 활용해 메시지를 구성할 수 있어 성능 면에서 유리하고, 이벤트 객체가 간결하게 유지됨

• 서비스 로직에서 필요한 정보를 이미 갖고 있어 중복 쿼리 발생하지 않음
• 알림 트리거는 이벤트로 넘기되, 메시지는 도메인 서비스에서 완성
• 메시지 포맷은 한 곳에서 생성되어 일관성 유지 가능

도메인 서비스가 알림 메시지까지 조립하는 단점은 있지만, 전체 시스템 구조 단순성과 성능 이점을 고려해 이 방식을 채택함.