공통 비즈니스 로직 분리(제휴사 인터페이스 통합 및 클래스 설계)

 

- 제휴사 API 서버 <> Npay 서버 연결 작업을 각자 진행한 후, 이를 하나로 통합하는 과정에서 비즈니스 로직 코드 중복이 발생함.

- 코드 중복을 해결하면서 제휴사 마다 다른 구현 사항을 고려하여 처음 설계한 아키텍쳐는, PointChangeService라는 abstract class에 공통 로직을 작성하고, 각 제휴사 마다 다른 부분은 abstract 메서드로 만들어 상속을 이용해 구현을 강제하는 방법이었음.

초기 아키텍쳐

- 그러나 서비스가 점차 커지고 코드가 복잡해지면서 순환 의존 (Cycle Dependency) 문제가 발생함. 

- 더불어 PointChangeService의 책임이 너무 많다는 문제점도 있었음. 결국 XXPointChangeService는 제휴사 마다 다른 구현부와 공통 비즈니스 로직을 모두 가지고 있는 클래스가 됨.

Cycle Dependency

sol) 순환 의존 문제를 제거하면서 동시에 PointChangeService의 책임을 나누는 유연한 설계로 변경함. 공통 비즈니스 로직은 PointChangeService에 작성하고, 제휴사 마다 다른 부분은 모두 제휴사 API를 사용하는 부분이었기 때문에 PartnerApiService로 분리함.

개선된 클래스 아키텍쳐

이와 같은 설계로 변경하면서 각 layer의 책임이 보다 명확해졌으며 라이브러리를 손쉽게 적용할 수 있는 등 보다 유연한 구조가 되었음.

상세 클래스 아키텍쳐