필요성
지난회 https://gunsight.tistory.com/36 에서 패키지를 한번 정리하고 모듈을 추가했었는데 각 역할 영역침범을 방지해주는 안전장치 역할로써는 훌륭하지만, 굳이 모듈 인프라가 필요 없겠다고 결론을 내린적이 있습니다. 이에 따라 이 작업의 대한 의의, 고찰을 하게 되었습니다.
답변해주신 맨토님께서는 현재 머기업 'ㅇ'사에서 재직중이신 훌륭한 현역 개발자이십니다.
https://hyeon9mak.github.io/woowahan-multi-module/
우아한 멀티 모듈 세미나 정리
권용근님의 우아한 멀티 모듈 세미나를 보고 정리한 내용
hyeon9mak.github.io
위 링크의 글을 인용하자면 워시핏에서 구성한 패키지 구조는 모놀리식 멀티모듈 구조를 따르고 있습니다.
패키지와 모듈 구조에 따른 고찰은 개인의 개발 가치관에 따라 달라진다고 생각하는 바, 디테일한 언급은 이자리에서 하지 않을 것이지만 결국 결론으로 귀결되는 사항은 '팀내에서 개발할 때 불편함이 없고, 생산성이 좋아지는가?' 였습니다.
이전 작업에서 https://github.com/Kernel360/F1-WashPedia-BE/pull/127 및 회의를 통해 코드리뷰를 거쳐 팀원분들의 의견을 종합 해보았을때 모듈을 새로 추가하여 이동시킨다면 테스트코드까지 헤비하게 뜯어고쳐야 하는 문제가 발생했습니다.
가뜩이나 다른 팀에 비해 개발속도가 느린 우리팀은 시간을 조금이라도 아끼고자 이번엔 모듈을 굳이 분리하지는 않되, 또 하나의 ORM을 추가 한 채 해당 ORM을 둘다 이용 할 수 있도록 패키지와 코드를 개선해보려고 합니다.
또한, 각 모듈의 역할을 고려하여 SERVICE에서 바로 ORM을 호출하는 방법을 지양하고, DOMAIN에서 추상화 객체를 하나 추가하여 SERVICE에서 어떤 ORM, 매개변수 객체를 보내는지에 따라 알맞는 ORM을 찾아가도록 바꿔보고자 합니다.
과정
MYBATIS ORM 추가
MYBATIS ORM 추가 방법은 1부 글을 참조해주시기 바랍니다.
우리 프로젝트의 훌륭한 실험체인 공통코드 호출을 통해 ORM 분리는 잘 된 것을 확인 할 수 있습니다.
build.gradle 정리 그리고 또 문제 발생
모듈의 각 역할을 생각하자면 api에선 jpa를 쓰지 않는것이 맞다고 판단되어 이 부분을 주석처리하고, domain을 의존성 추가하였습니다. 의도대로라면 이렇게만 했어도 정상 작동이 되야합니다.
그러나 의도와 다르게 의존성을 추가하였음에도 찾을 수 없다는 에러가 발생을 하게 됩니다. 이에 따라 service에서 바로 orm을 호출하는 repository를 찾도록 하는 것이 아닌, module-domain에서 위에서도 언급했었던 repository 클래스를 하나 만들어 이 부분을 해결하고자 했습니다.
service 코드를 모두 ORM 클래스를 바라보도록 하였는데, 이런 저런 수정을 다 하여도 static 컨텍스트 에러가 발생하였습니다. 처음엔 각 모듈간 정합성같은 무언가 싱크문제일꺼라 조심스레 추측했었으나 service.java가 있는 api 모듈과 ORM.java가 있는 domain 모듈 둘다 jpa 의존성을 넣었음에도 동일한 에러가 발생하는 것을 보아 원인은 아직 잘 모르겠지만, 이전 작업 내용의 레포를 살려두었기 때문에 동일한 문제가 발생하는지 나중에 확인해봐야겠고 작업을 mybatis만 쓸 수 있는 상태로 롤백한 뒤 여기까지만 하도록 해야겠습니다.