- 아키텍쳐
조회 승인 취소 로만 보면
조회
-
조회 상위 서비스 (RetrieveService)
-
조회를 위한 고객사 실제 요청 서비스 (CouponShopService) -> 팩토리 패턴으로 구현해놓았다. (즉 같은 타입의 Response 를 뱉는다)
승인
-
승인 상위 서비스 (ApproveService)
-
승인을 위한 고객사 실제 요청 서비스 (CouponShopService) -> 팩토리 패턴으로 구현해놓았다. (즉 같은 타입의 Response 를 뱉는다)
취소(마찬가지)
충전 로직
현재 충전 로직을 수행하는데, 해당 아키텍쳐는
-
충전 서비스 (상위)
-
조회 서비스 (하위)
-
승인 서비스 (하위)
시퀀스는
조회 -> 승인 (이 시점에 히스토리를 DB에 저장한다) -> 충전
이 과정은 충전 서비스의 한 매서드에서 일어난다
문제가 뭐냐?
데이터가 들어오는 곳은 (레거시 로직 기준)
-
Controller
-
조회 서비스
-
승인 서비스
이 모든곳에서 데이터를 받는다. (정확히는 set한다)
심지어 같은 데이터를 set하는 경우가 너무 많다(map 으로 put 하고 있으므로)
예를 들어 조회에서 가져온 주문번호(orderNo) 를 승인에서는 재발급해서 사용한다던지...
그래서 이 모든 데이터의 입출력을 setter가 없는 VO 객체로 선언해서 뽑아주고 있는데, 문제는 충전 로직(즉 최상위 로직)에서 하위 로직들(조회, 승인, 취소)의 중복된 데이터(예를 들면 orderNo)를 적절히 핸들하기가 어렵다는 것이다.
1. 현재 Charge Service 측에서 사용하는 VO가 너무나도 많다.
- controller 에서 들어온 vo(request)
- 조회 응답 VO
- 승인 응답 VO
심지어 이 녀석들의 의존관계가 너무 심각하게 꼬여버렸다. (썩어버렸다 진짜로)
승인 응답을 위해
1.조회 응답 vo
2.컨트롤러 요청 vo
둘 다 필요한 상황에다가
승인, 취소를 위한 requestVO의 생성도 이 응답 VO들이 하고있다. (왜냐면 조회에서 가져온 데이터들 (예를들면 금액) 을 승인, 취소에서 필요로 하기 때문)
이 로직을
- 보기 편하고 (즉 데이터가 어떻게 오고 나가는지 명확하게 보이고)
- 확장 가능하게 (느슨한 의존으로)
바꾸고 싶다. 방법이 없을까?
생각한 방법은
- 일단 매소드별로 분리
- 조회 매서드 분리
- 승인 매서드 분리
해당 작업만으로도 많이 분리가 되었다. 이 과정에서 데이터를 조금 정제하게 되었고, 해당 매서드 (이 모든 시퀀스를 포함하는 부모 매서드) 에서는 데이터가 중구난방으로 튀어서 헷갈릴 일을 줄였다.
다만 이 경우에도 아직 response 객체를 가지고 승인, 취소의 request 객체를 만들어야 한다는 점이 맘에 걸린다. 너무 강한 의존을 걸어주는 것은 아닌지?
- 근본적인 문제 해결 방법이 없을까?
현재 조회, 승인, 취소 모두 비슷한 값을(필드를) 가지는 response 객체를 리턴하고 있다. (같은 타입의)
이 문제로 인해서 내가 어려움을 겪는 것은 아닐지 생각이 된다. 히스토리를 남기기 위한 필수 필드들을 남기고, 마이바티스 쿼리 자체를
- 조회 히스토리 저장
- 승인 히스토리 저장
...
등과 같이 변경해서 null 인 필드가 없는 데이터를 선언하는 게 더 도움이 될 것 같다.
다만 이 경우 고객사마다 건네주는 데이터가 다른 경우가 왕왕 있어서...그것이 문제이다. 예를 들어 조회에서 건네받은 특정 "key" 라는 필드가 승인 요청에 필요 할 수가 있다. -> 이 부분에 대한 해결을 고민해봐야 하는데...어렵다.
근본적으로 팩토리 패턴을 사용하지 않아야 하는가? 라면...모르겠다. 응답이 90퍼센트 정도는 비슷하고 딱 한개의 서비스만 저 "key" 라는 값을 가지는데...조금 두렵다.
더 두려운 것은 내가 리팩토링을 아직 진행하지 않은 다른 곳에서 이 param 이라는 고봉밥 HashMap에 뭘 또 담고 put 할 수 있다는 점이다.
