관심사 분리
'관심사 분리' 는 소프트웨어 개발 아키텍처의 중요한 근간이 아닌가 싶다.
현재 글은 MVC패턴의 결과물인 Controller-Service-Repository에 관한 글이 아닌 스프링부트의 각 Layer간의 Beans 들을 어떻게 관리할 것인지에 대해서 내 나름대로 생각해보고 정리해 본 결과이다.
1. Mess Up(fxxk up) Pattern
(제목의 패턴 이름은 내가 이름 붙힌 패턴이다..)
가장 피해야 될 상황이 아닌가 싶다..
혹시나 현재 다니고 있는 회사의 동료들이 이 글을 보게 될까 걱정되지만
전혀 그런 의도가 아니고 올바른 결과를 위한 과정이라고 이해해주었으면 좋겠다.
├── frontend
│ ├── public
│ ├── src
│ package.json
├ ...
├── backend
│ ├── Admin
│ ├── api
│ │ ├── controller
│ │ ├── service
│ │ ├── repository
│ │ └── ...
│ ├── controller
│ ├── Service
│ ├── config
│ └── ...해당 패키지 구조를 유지보수의 업무로 갓 입사한 신입 개발자가 보았다! 무슨 생각을 하게 될까?
-
frontend? backend? 뭐지? 하나의 패키지 안에 front랑 back을 같이 집어넣은건가? 왜 resource 파일 안에 html, js파일을 안놨지?
-
backend 패키지 안에 api 패키지도 있고 그 외부에도 controller, service가 있네? 이건 뭐지? Admin은 관리자페이지고 api는 사용자 화면인가? 그럼 frontend 패키지는 뭐지?
-
Admin, Service 같이 패키지이름을 왜 대문자로 적었지? 뭔가 특별한 이유가 있는걸까?
...
해당 사례는 나의 경험이었다. 하나의 Repo 안에 frontend(React.js)와 backend가 같이 있어 build.gradle에서 frontend 모듈을 갖다 붙여주는 groovy 코드가 있었다.
이러다 보니 매번 실행 해줄때마다 리액트 코드와 스프링부트가 같이 실행되다 보니 Run 시간이 30초씩 걸리곤 했다..
"관심사의 분리" 라는 키워드를 난 입사하자 마자 이해하게 되었다.
ps.
물론 해당 프로젝트의 담당자 분들도 신입으로 바로 프로젝트에 투입되어서 이리저리 구르면서 만든 프로젝트라고 듣게 되었고 해당 프로젝트를 나에게 보여주는 것에 대해 굉장히 부끄러워 하였고 많은 도움을 주셨다.
2. api - global
해당 패키지 구조는 나의 첫 프로젝트때 작성한 패키지 구조이다.
후에 3번에서 후술할 방법을 생각하기 전에 블로그에서 보고 참조해 구현한 구조이다.
- api, admin
- 사용자와 관리자 화면에 있는 도메인과 비즈니스로직을 작성하는 패키지이다.
- database에 접근하는 repository도 같이 작성되어있다.
- 전보단 깔끔해졌지만 아직도 아쉬운 점이 꽤 보인다.
- global
- 공통으로 사용되는 부분들을 전부 빼서 넣어주었다.
- 스샷을 보면 알 수 있듯. 도메인 로직을 생각한다면 api, admin 패키지를 공통의 common 요소들의 작성을 생각한다면 global 패키지를 보게 하도록 만들었다.
지금의 내가 이 패키지 구조를 보고 Feedback 해야한다면
- 결국 클라이언트의 요청이 데이터베이스까지 접근하는 과정에서 하나의 패키지 안에 꽤나 다양한 부분을 담고 있어 패키지 하나하나가 너무 거대하다는 느낌을 받는다.
- Database에 접근하는 layer를 충분히 분리할 수 있을것 같다.
위의 아쉬움을 통해 바꿔보고 만족스럽게 진행한 패키지 구조이다.
3. Multi Module
멀티모듈에 관한건 원래부터 들어오기만 했다.
헌데 이 패키지 구조에 하나하나의 과정을 겪어본 나로써는
프로젝트를 진행할 때마다 멀티모듈의 필요성을 느끼게 되었고
https://jojoldu.tistory.com/123
jojoldu 님의 블로그를 참조하여 작업을 시작하였다.
해당 구조로 바꾸고 나서 내가 느낀 가장 큰 장점은
도메인과 DB를 분리할 수 있다는 점 이었다.
즉, 이 글의 골자인 관심사의 분리를 지킨다는 점이었다.
api - 클라이언트의 요청과 비즈니스 로직의 작성
database - api 모듈에서 전달받은 요청으로 원하는 데이터를 가져와 퍼올려주는것
global - api와 database에서 사용하지 않는 공통 컴포넌트, 외부 라이브러리, 예외처리, config 파일들을 모아두는 곳
물론 해당 멀티모듈에서도 궁금한점이 생겼는데
멀티모듈의 이해도가 깊지 않아 생긴 의문이다.
보통은 api 모듈의 build.gradle에서 database와 global모듈을 implementation 하게 된다.
하지만 필연적으로 global 모듈에서도 모든 공통작업들을 담당하다보니 api와 database의 모듈을 implementation해야하는 상황이 생기는데
이렇게 되면 api와 global 모듈은 서로 각자의 모듈을 가져와야해서 더 복잡해진 세팅이 된것이 아닌가 하는 의문이다.
해당 문제에 대해선 더 깊게 조사해보고 사용해봐야겠다고 생각하게 되었다.
마무리
사실 프로젝트의 규모에 따라 구조는 충분히 바뀔 수 있다고 생각한다.
화면이 20개도 안나오는 프로젝트에 아무리 확장성을 고려한다 해도
굳이 멀티모듈까지 적용할 필요없다고 생각한다.
단, 관심사의 분리를 생각해서 작성한다는 것이 단순히 현재뿐만 아니라 후에 2차, 3차 개발자에게까지도 전파된다는 것을 꼭 생각해보길 바란다..
