작성자 : 김다희
api를 개발하면서 아래와 같은 순환 참조 에러 코드를 마주했다!
문제
- articleService, seriesService 를 순환 참조
Description: The dependencies of some of the beans in the application context form a cycle: articleController defined in file [/Users/Kimdahee/prgrms-dev/finalProject/Team_Sagack_MonthSub_BE/build/classes/java/main/com/prgrms/monthsub/module/series/article/app/ArticleController.class] ┌─────┐ | articleService defined in file [/Users/Kimdahee/prgrms-dev/finalProject/Team_Sagack_MonthSub_BE/build/classes/java/main/com/prgrms/monthsub/module/series/article/app/ArticleService.class] ↑ ↓ | seriesService defined in file [/Users/Kimdahee/prgrms-dev/finalProject/Team_Sagack_MonthSub_BE/build/classes/java/main/com/prgrms/monthsub/module/series/series/app/SeriesService.class] └─────┘
현재 상황
- erd
시리즈 하위 글쓰기 ( = 아티클), 시리즈가 n : 1 연관관계 매핑이 되어있다.
- 시리즈 서비스에서는 아티클 서비스가 필요하다.
- 연관관계이기 때문이다.
- 시리즈 1개 데이터를 조회할 때 시리즈 1개 하위에 작성된 n개의 아티클 정보를 같이 내려줘야하는 비즈니스 요구 사항을 만족해야한다.
- 아티클 서비스에서는 시리즈 서비스가 필요하다.
- 연관관계이기 때문이다.
1차 해결 방법
단순하게 생각했을때에 아래와 같은 해결법정도가 떠올랐다. 사실 어떤 해결 방법을 택하던 차악에 가까웠다.
API를 빠르게 만들기위해 공수가 가장 적은 방법인 3번 방식을 택했다.
설계를 다시한다.- 일정에 맞춰서 빠르게 개발을 진행해야했기 때문에 설계부터 다시하기엔 공수가 너무 컸다.
연관관계를 맺지않는다.- 시리즈와 아티클은 연관관계 매핑이 꼭 필요한 상황이다.
- 아티클 서비스에서 시리즈 레포지토리에 바로 접근한다.( 또는 시리즈 서비스에서 아티클 레포지토리에 바로 접근한다.)
- 단일 책임 원칙을 깨야하지만 가장 공수가 적기때문에 이 방식으로 채택!
비즈니스 요구사항을 바꾼다.- 핵심 비즈니스 요구사항이기 때문에 비즈니스 요구사항을 바꾸는건 어렵다고 판단했다.
2차 해결 방법 ( 최종 )
변경 전
다음과 같이 3계층으로 이루어져 있고, 서비스에서 서비스를 참조하는 상황이었다.
- Controller → Service → Repository
변경 후
서비스에서 여러개의 서비스를 참조하는 형식이 아닌 여러 서비스를 관리하는 상위 계층을 구성하였다.
여러 서비스를 관리할 수 있는 상위 레이어를 하나 구성했고, 서비스에서 서비스를 참조하지 않을 수 있도록 하였다. 상위 레이어는 Assemble 이라는 이름으로 명명하기로 했다.
- Controller → Assemble → Service → Repository
- Controller는 단일 Assemble 또는 단일 Service를 참조할 수 있다.
- Assemble은 n개의 Service를 참조할 수 있다.
- Service는 단일 Repository를 참조할 수 있다.
이번 문제를 해결하면서 역할이 왜 중요한지 느끼게 되었다.
상위 레이어를 감싸야한다는 아이디어가 떠오르기전에는
공수가 많이 들어가는 엔티티 설계를 다시 뒤집어야 하는 방식,
서비스에 직접적인 영향을 끼치는 비즈니스 요구사항을 바꾸는 방식 등과 같은 방식만 생각이 났는데,
조금 생각을 전환하니 공수도 크지 않고, 아키텍쳐 구조도 견고해질 수 있는 해결책을 찾을 수 있었다.
지금 단계에선 마주하는 문제는 어느정도 정답이 있는 문제라고 생각을 많이 했는데,
(이 문제도 어느정도 정답이 있는 문제일 수도 있지만?!) 그런 고정 관념에 얽매이지 않고
현재 프로젝트에 맞는 규칙과 방식을 가져가는게 베스트라는것을 알게 되었다!