인프런 커뮤니티 질문&답변
작성한 질문수
부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?
작성
·
18
1
addReview()를 보면 리뷰 저장 이후에 포인트를 지급하는 로직이 함께 들어가 있는데, 제 기준에서는 포인트 지급이 리뷰 작성의 핵심 기능이라기보다 부가 기능처럼 느껴졌습니다.
그래서 이런 부분은 서비스 내부에서 직접 호출하기보다 이벤트를 발행하고, 별도의 핸들러에서 처리하는 방식으로 분리해도 괜찮지 않을까 궁금했습니다.
(다만 제가 이걸 정말 "부가적인 책임"으로 봐도 되는지 조금 헷갈리기도 합니다.)
만약 실무에서는 이런 부가적인 로직을 서비스 메서드 안에 함께 둘지, 아니면 이벤트/이벤트 핸들러 형태로 분리할지를 어떤 기준으로 판단하시는지 궁금합니다.
또는 이런 경우 이벤트 외에 다른 방식으로 설계하시는 경우도 있는지 궁금합니다.
답변 2
1
안녕하세요 질문 감사드립니다!
제 경우는 비즈니스와 비즈니스로직의 응집도를 좀 더 중요하게 생각합니다
그러다 보니 포인트 지급에 대한 부분을 별도 이벤트 발행으로 처리하기에는 응집도가 떨어진다고 느껴지는 것 같습니다
또 비즈니스적으로 리뷰 작성과 포인트 지급이 상당히 가까운 개념적 관계에 속한다고 볼 것 같습니다
(물론 논리적으로 "포인트는 글로벌하게 쓰이니 이벤트로 처리해도 되는거 아닌가?" 라는 생각도 틀리진 않습니다)
결국 이벤트 기반 처리를 오용하게 되면 응집이 깨지는 문제가 있다고 생각 합니다
그래서 저는 일반적으론비즈니스적 맥락이 완전히 분리 될 때 를 기준으로 이벤트 기반으로 처리하는 것 같습니다
(ex] 이메일 발송, 알림톡 발송, callback 전송 등 완전히 다른 비즈니스/기능적 맥락)
약간 다르지만 비슷한 관점으로는 동시성 관점으로 후 처리 or 비신뢰 처리가 되어도 된다라면 @Async 를 사용하는 경우가 있는 것 같습니다
모쪼록 답이 되었길 바랍니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. gogo님.
질문해주신 내용은 시스템 설계와 관리측면에서 매우 중요합니다. 특히 모듈성을 높이고, 코드의 유지보수성을 높이기 위해 중요한 결정이기도 합니다.
이벤트 핸들러로 분리하는 기준
비즈니스 중요도: 포인트 지급처럼, 부가적인 내용이 비즈니스 작동의 필수적이지 않은 부분이라면 이벤트로 처리하는 것이 좋습니다. 그 이유는 이벤트를 통해 비동기로 처리하거나, 실패 시 롤백하지 않음으로서 메인 로직과의 결합도를 낮출 수 있기 때문입니다.
루즈 커플링(Loose Coupling): 서비스와 부가적인 기능 간의 의존성을 줄이는 것이 목표라면 이벤트 패턴은 좋은 선택이 될 수 있습니다. 이벤트는 동작간의 결합도를 줄여주고 개별 기능에 대한 독립적인 테스트 및 변형을 용이하게 만듭니다.
확장성: 향후 포인트 기능이 여러 곳에서 사용되거나 확장 가능성이 크다면 이를 이벤트로 분리함으로써 재사용성과 확장성을 높일 수 있습니다.
실패 내성 (Fault Tolerance): 포인트 지급이 실패해도 비즈니스 로직에 큰 영향을 주지 않는다면, 별도 이벤트로 처리해서 메인 플로우가 해당 실패에 의해 영향을 받지 않도록 할 수 있습니다.
다른 설계 방법
이벤트 외에는 CQRS (Command Query Responsibility Segregation)를 사용하여 읽기와 쓰기를 분리함으로서 복잡성을 줄이는 방법도 있습니다. 특히, 복잡한 상태의 변경 로직이 필요할 경우 이벤트 소싱(Event Sourcing)과 함께 사용되기도 합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변 감사합니다!