공통 검증 메서드 모듈화 및 메서드 분리

프로젝트를 진행하면서 검증이 필요할 때가 많다.

 

예를들어 DB에 진짜 있는 값인지 또는 바로 밑에서 언급할 가입 회원의 탈퇴 상태값 등이 있다.

내가 진행한 프로젝트의 경우 회원이 탈퇴하면 로우 자체를 삭제하는 것이 아니라 is_deleted 라는 컬럼의 상태값만 바꿔준다.

그래서 JPA에서 제공하는 findById를 써도 is_deleted가 true인 값까지 가져오게 된다.

 

그래서 검증 메서드를 MemberService에 밑에 사진처럼 만들어놨다

 

MemberService 자체에서만 사용하게 된다면 문제가 없다

 

문제 

하지만 ReviewService나 StoreSevice같은 다른 클래스에서 사용하게 된다면 

getMember라는 메서드가 많이 필요하게 되고 클래스마다 메서드를 추가하게 되고

ReviewService에서 MemberRepository를 의존하게 된다.

 

그렇게 프로젝트를 진행하다 보니 중복코드가 너무 많아졌고 이렇게 쓰는게 맞나? 싶었다.

 

그래서 메서드를 하나만 사용하기로 결정했다.

 

해결 1

 

우선 ReviewService랑 StoreService에 MemberService를 의존하게 만들었다.

 

 

 

이렇게 만들고 보니까 createReview에서 memberService.getMember()가 생기니 단일 책임의 원칙을 위반한다는 생각이 들었다.

 

하지만 무조건 필요한 코드이기 때문에 그냥 없앨수는 없었다.

 

그래서 생각한 두 번째 해결 방법이 검증하는 코드는 컨트롤러에서 해결하고 서비스로 넘겨주는 해결책을 생각했다.

 

해결 2

 

 

컨트롤러에서 멤버 검증을 하게 만들었다.

 

 

컨트롤러에서 검증을 하다 보니 MemberService를 의존하지 않게 된다.

 

 

이제 리뷰를 만드는 역할만 하는 것을 볼 수 있다.

 

 

고민점

하지만 리팩토링을  했는데도 생기는 고민이 많다.

 

• 컨트롤러에서 다른 서비스를 의존하는 것.
  • 단일책임의 원칙을 지키냐 vs 컨트롤러에서 다른 서비스를 의존하냐

위 두개의 관점에서 트레이드 오프를 해야하는 거 같지만 아직도 뭐가 더 좋은 방식인지는 모르겠다.

 

 

• 단일책임의 원칙을 지킨다 하였지만 createReview에서 imageService를 의존한다는 점.
  • 어떻게 보면 단일책임이 맞지만 이미지를 넣어주는 것이 따로 빠져야 하나? 라는 생각이 든다.

이것도 빠지면 좋겠다는 생각이 들고 또 너무 많이 분리하는 것 또한 가독성이 떨어질 수 있다고 생각이 들고

이 또한 트레이드 오프인것 같다.

 

---

 

항상 뭐가 맞다 아니다 라는 정답이 없어 팀 프로젝트를 진행하면 코드를 짜다가 급 토론을 하게  된다.

나 혼자 고민하는 것이 아닌 팀원과 고민하다 보면 트레이드 오프 지점이 생기게 된다.

오늘도 모듈화를 진행하면서 어느 정도 성장했다는 느낌이 들지만 항상 정답이 없어 더 깊은 고민에 빠지게 되는 계기가 됐다.