기존에 개발 했었던 이슈트래커를 설계, 조회방식 등을 바꾸면서 리팩토링도 하면서, 기능도 좀더 추가 해보면서 다른 문제를 발견하게 됐습니다.
스프링의 빈 객체간 DI로 순환참조 문제
- IssuerService 와 MilestoneService 각각이 서로간에 의존하며 참조하고 있었습니다. 테스트로만 확인하며 작업하다가 실제 애플리케이션 실행시키면서 발견했는데요.
- 테스트와 실제 동작은 다른 걸 느끼기도 한 과정이었습니다.
(라벨 서비스 의존관계는 나중에 없애려고 ...)
저는 첫 번째로 왜 서로 참조하게 되었는지 로직을 다시 확인 해 봤습니다.
기존에는 이슈트래커 개발 당시 조회 로직 중심으로 개발했었는데요. 라벨과 마일스톤은 등록도 했었지만, 이슈는 통합검색 기능 구현하면서 나중에 하자며 제외 했던 기능이었습니다.
새 기능 추가로 문제 발생
- 예상 가능 한 기능 이었지만, 좀더 고민하면 좋은 점은 등록된 빈간의 의존관계를 확인 해보기
조회만 해오던 서비스의 비즈니스로직에서 등록이 생기면서 발생한 문제였습니다.
그러면 라벨과 마일스톤에서는 이슈를 등록하지 않았었나?
(리팩토링 하며 개발한 것도 두 달? 전이라 ㅎㅎ 바로 떠오르진 않고 다시 확인해봤습니다.)
라벨 등록시에는 라벨 정보만 입력하여 저장하고, 마일스톤도 동일 했습니다.
이슈 등록시에는 새 라벨 등록이 아닌 저장되어 있는 라벨과 마일스톤 목록을 통해 저장하고, 이는 관계로 인한 데이터이지 새로 추가 저장되는게 아니었습니다.
저는 이번에 작업하면서 다른 도메인과 관련 없으면 하나의 도메인 패키지 내로 엔티티들을 모아 봤는데요.
기존에 서비스에서의 의존관계에 대해 동일 패키지 이면 Repository로 생성자 주입 받게 하고, 외부 패키지 이면 서비스를 통해서 주입 받게 했습니다.
(주관적인 생각입니다. 어떤 지식이나 방식이 아니라, 이유는 다르게해서 차이를 알면, 개발경험이 되니까요 ㅎㅎㅎㅎ 이래서 면접 준비가 bad ... )
동일 패키지 내 의존관계는 Repository로,
다른 패키지 도메인간의 의존관계는 Service를 참조하게 합니다.
다시 정리하면,
기존에 이슈 서비스에서 없던 저장 로직 추가로 마일스톤 참조관계 발생
- 마일스톤 조회 결과가 필요
마일스톤은 조회시 이슈 상태별 개수를 위해 이슈 서비스를 참조
- 이슈 조회 결과가 필요
요구사항 다시 분석 해보기
- 이슈 등록시 라벨과 마일스톤을 목록 중 선택합니다.
- 이슈 등록하면서 라벨 등록X, 마일스톤 등록X
- 라벨 등록은 라벨 정보만 사용합니다.
- 마일스톤 등록시 마일스톤 정보만 사용합니다.
그 외...
- 라벨 목록은 라벨만 조회합니다.
- 마일스톤 목록은 이슈 상태별 개수 조회 정보가 필요합니다.
제가 한 번 이지만...ㅎㅎㅎ
기획하면서 개발을 해보니 좀 다른 관점으로 보게 된 것 같아요.
검색하니 @Lazy 사용이나 세터 등의 방식들도 스프링스럽게 생각 해도 되는 구나 싶었습니다. (복습이라도 꾸준히 .. 😑)
저는 저장은 도메인 내에서만 발생하고, 조회는 다른 도메인에서 참조가 많다고 보았습니다.
엔티티 자체도 무관한 데이터를 하나의 클래스 안에 갖고 있지 않을 것이고,
관계를 통해 불러올 데이터들을 FK로 가지고 있으면서 조회해오지, 동시에 분리된 도메인 저장해서 분리한 인터페이스 간에 순환참조하게 될 일은 없었습니다.
- 이렇게 설계하는구나.
- 제가 말한 건 패키지 단위로 관계가 먼 경우 분리된 상태에서, 생성만 보였는데요.
- 혹시나, 수정은... 더 생각해 봐야 할 것 같아요. 😖
그래서 Repository를 store와 reader 인터페이스로 사용하기로 했습니다.
동일 도메인의 Service에서 store와 reader를 참조하지만,
다른 도메인에서는 reader 만을 참조 할 거라는 생각이었습니다.
Repository를 2개의 역할로 나누기 위해 인터페이스를 추가하면서 Repository의 변경에 대한 영향도 줄일 수 있어 좋은 것 같아요.
이번 경험으로 다른 관점도 얻고, 다양한 방식들도 보면서 재미있어서 정리해 봤습니다.
좋은 의견이나 지식 첨언은 감사히 받겠습니다. 🙂
재미는 있었는데.. 패키지 바꾸고, 클래스 바꾸고, 메서드명 새로 고민하고, 테스트 바꾸고.. ㅎㅎ
- 간단한 경우라면, 추천하지 않는다지만 @Lazy나 세터를..
