일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- multimodule
- 스프링
- 문서화
- 프론트엔드
- 스프링배치
- 서브모듈
- batch
- 스프링부트배치
- 성장
- batchframework
- batch framework
- 스프링부트
- submodule
- 백엔드
- react
- springbootbatch
- springboot
- 스타트업
- spring
- Kotlin
- 회고
- 멀티모듈
- API
- springrestdocs
- Today
- Total
노트북을 열고.
[SubModule] 1. SubModule 혹은 MultiModule? 본문
커뮤니티 서비스를 개발하고자 합니다. 기본적으로 아래와 같이 각 역할을 담당하는 서버를 따로 분리하여 설계를 하고자 합니다.
WEB module : 서비스 이용자와 접점을 담당하는 모듈
API module : Web페이지 내부에서 직접적으로 연결을 담당하는 서비스 또는 DB와 접점을 당하는 모듈
Batch Module : 일정한 스케쥴을 주기로 일괄처리 서비스를 담당하는 모듈
ㅡ 분리를 해야하나요?
꼭 그렇게 안 하셔도 됩니다. 왜냐하면 그것으로 우리가 구현해야하는 서비스를 구현하지 못하는 사례는 없을 테니까요. 하지만 우리는 더없이 게으르게 싶고 움직이고 컴퓨터는 더없이 빠르고 척척 알아듣게 만들고 싶어 하는 천성 개발자(혹은 개발 지망생)입니다. 두 번 거쳐해야 할 일을 단 한 번에 끝낼순 없을지라도 한번에 할 일을 두 번, 세 번 반복해서 하는 경우는 적어도 없어야겠죠.
자, 다음의 그림을 한번 살펴봅시다.
흔히 볼 수 있는 단일 프로젝트 구성입니다.
그러니까 위에서 언급한 Web, API, Batch 그리고 Member, Order, Item과 같은 도메인 영역의 클래스가 한데 어우러져 있네요. 하지만 이러한 구성은 당초 설계하고자 하는 방향과는 맞지는 않습니다. 우리가 만들고자 하는 커뮤니티 서비스는 1년이 지나고 10년이 지나서도 많은 이용자들이 매일매일 찾아오게 만드는 서비스를 만들 겁니다.
시간이 지날수록 이용자 동시접속수는 기하급수적으로 늘어날 것이고 그에 상응하는 서비스 역시 점차적으로 다양화되고 비대해질 것입니다. 그렇기 때문에 우리는 처음부터 각 서비스의 역할을 명확하게 나누어 그 목적에 맞는 서비스를 개발해 갈 것을 지향해야 합니다.
이 점을 상기시키고 다시 프로젝트를 설계해 봅시다.
위에서 언급한 대로 각 역할을 담당하는 서버별로 분리하여 설계하였습니다. 그런데 무엇인가 마음에 들지 않습니다. Member, Order, Item과 같은 도메인 영역의 클래스가 각 서버마다 붙어 있습니다.
예컨대, 각 회원들이 관심사에 따라 모임을 결성할 수 있는 서비스를 만든다고 칩시다. 기존의 Member클래스에 새로운 멤버 속성이 추가될 것이고 새로운 도메인 클래스(가령, Group)를 정의해야 할 수도 있을 것입니다. 그 경우 우리는 동일한 성격, 동일한 문자, 동일한 글자 수를 갖는 클래스를 각 모듈 수만큼을 반복적으로 만들어야 할 것입니다.
반대로 한 개의 서비스나 기능이 수정되거나 삭제되어야 할 때도 마찬가지입니다. 우리는 동일한 작업을 모듈의 수만큼 반복되어야 할 것이고 모듈의 수만큼 피로도 쌓일 것입니다. 물론 모듈의 수만큼으나 서비스 이전에 검증해야 하는 관리 포인트도 늘어나는 거겠죠.
이쯤이면 답이 보이실 것도 같습니다.
왜 분리해야만 하는지를.
그래서 나온 프로젝트 구성도의 최종 설계안은 다음과 같습니다.
앞서 시행착오를 거치면서 우리는 다음의 설계조건을 만족하는 설계안을 도출해 냈습니다.
- 1개의 프로젝트 안에 각각의 역할을 명확히 나누어진 모듈을 구성한다.
- 각 모듈의 공통으로 갖는 클래스를 별도의 공통모듈을 구성하여 참조하도록 한다.
- 각 모듈에 필요한 의존성(dependencies) 역시 1개의 설정(Propoerties) 안에 구성되도록 한다.
프로젝트를 설계하는 과정은 서비스를 완성하고 유지해 가는데 매우 중요한 일종의 기초공사입니다. 물론 제가 소개한 프로젝트 구성이 모든 여건과 상황들을 충족시켜주진 않습니다. 동작 그만 밑장 빼기냐?
하지만 프로젝트를 착수하기 전 우리가 어떠한 구조와 방향으로 서비스를 구현해 나아가야 하는지를 한 번쯤 고민해 볼 수 있는 작은 이정표 정도로만 봐주셨으면 감사하겠습니다.
이어서 다음 편에서는 해당 프로젝트 설계안을 토대로 직접 구현하는 시간을 가져보겠습니다.
'아는 것'보다 '알아야할 것'이 더 많은 늦깎이 주니어개발자입니다.
알고 있는 지식을 전한다는 목적 보단 막 알게된 지식을 스스로 정리하는 차원에서 포스팅하고 있으니 잘못된 내용이나 부족한 부분이 있더라도 겸허한 이해 부탁드립니다. 댓글이나 쪽지를 통해 첨삭의견주시면 감사히 수렴하고 보완하겠습니다.
'SpringBoot' 카테고리의 다른 글
[spring boot batch] 2. 미납회원 배치처리 구현 (876) | 2019.07.30 |
---|---|
[spring boot batch] 1. 간단한 대용량 배치처리, 스프링부트배치 (785) | 2019.07.30 |
[SubModule] 4. 프로퍼티 설정하기 (432) | 2019.07.30 |
[SubModule] 3. 멀티 모듈생성 (425) | 2019.07.30 |
[SubModule] 2. 프로젝트 생성 (445) | 2019.07.30 |