서론
프리랜서로 근무하면서 Spring Event를 사용하게 됐고 이 때 내가 생각한 점을 정리 해보려고 한다.
Spring Event
Spring Event는 간단히 말해서 행위에 대한 Event를 발행하고 그 Event를 구독하고 있는 부차적인 로직을 실행하도록 해준다. 이 때 장점은 메인 비지니스 로직에서 부차적인 로직에 대한 의존성을 분리 할 수 있다는 점이다.
사용하면서 생각한 문제점
실제 프리고 근무한 곳에서는 Spring Event를 좀 철학에 안맞게 사용하고 있다고 생각했다.
이유는 하나의 메인로직에 모든 부차적인 로직에 대한 Event 각각 발행했고, 부차적인 로직 또한 또 다른 로직에 Event를 발행에서 하나의 로직에 Event가 체이닝 되어 있는 상황이었다.
위 상황에 대한 문제
-
하나의 메인 로직에 어떤 부차적인 로직이 있는지 파악하기가 힘들다. 각각 부차적인 로직에 대한 Event 및 체이닝으로 걸려있는 Event까지 확인하기가 여간 힘든게 아니었다. 마치 Event가 트리형식으로 물려있었다.
-
유닛 테스트를 진행하지는 않았지만 메인로직만 하더라도 1~n개의 Event가 발행 중이어서 유닛 테스트를 진행했다면 모든 Event를 테스트 더블을 만들어 줘야지만 한다.
-
메서드 재사용를 재사용 하기가 무서웠다. 재사용하고 싶은 메서드에 어떤 Event가 발생하고 있고 어떤 Event가 체이닝으로 물려있는지 파악을 매번해야했고, 때문에 같은 로직에 Event만 없는 메서드를 만들기도 햇다.
내가 제시한 해결책
하나의 메인 로직은 1개의 Event만 발행하자
하나의 메인 로직은 1개의 Event만 발행하고 모든 부차적인 로직들이 구독을 해야 어떤 기능들이 물려있는지 파학하기가 쉽다고 생각했다. 또한 유닛 테스트를 진행할 때도 Event하나만 테스트 더블을 만들면 되기 때문이었다.
그리고 가장 중요한건 Spring Event의 철학이라고 생각했다. Event를 구독 중인 로직들은 EventListener를 통해 구독하는데 워딩 그대로 Listener가 Event에 종속적이 어야하지, Listener에 대해 각각 Event를 만들어 넘겨주는건 종속이 역전된다고 생각했다.
결론은 기각됐고 다음 의견을 제시했다.
타 도메인의 부차적인 로직만 Event를 발행해주자
DDD방식의 프로젝트 구성이었기 때문에 여러 Event를 발행할 것이라면 타 도메인의 기능에 관한 것들만 Event를 발행하고, 같은 도메인의 부차적인 로직은 그냥 DI를 받아서 사용하면 Event를 최대한 줄일 수 있다고 생각했기 때문이다.
수많은 Event을 발행하고 그 Event 역시 Event를 발행하는 무수한 트리형식의 Event는 관리도 어렵기 때문에 최대한 Event를 줄이기 위한 차선책으로 제시를 했다.
하지만 이 역시 기각되어 좀 아쉬웠다.
결론
내 제안이 정답이 아닐수도 있다는건 인정한다.
하지만 모든 제안이 기각되어 변한게 없었지만 프리를 하면서 어떤 마음가짐을 가져야할 지 많은 생각을 하게 됐었다.
프리로 근무하면서 이렇게까지 기존의 방식을 바꾸자고 어필하는게 나한테 득이 될까? 괜히 트집으로만 보이는게 아닐까? 하는 생각들을 했다.
그래도 몇 달을 같이 일하게 될 동료고 내가 프리를 그만 두고도 남은 사람들이 좀 더 편하게 일했으면 좋겠다는 생각으로 했던 제안들이었고 아직 내 제안이 유지보수하고 메서드를 재사용 하기가 편리하다는 생각한다.
