TIL_013 | Multi Module (1)

묘한묘랑·2023년 12월 13일
0

TIL

목록 보기
13/31
post-thumbnail

오늘은 Sparta 국비 교육을 들으며 튜터님과 방향성에 대한 이야기를 하던 도중 아키텍처와 Multi Module에 관한 이야기와 미션을 받게 되었다.
모르고 넘어갔다가 나중에 알게 되었으면 정말 눈물을 흘릴 정도로 재밌어 보였다.
사실 튜터님이 없었다면 관련 KeyWord를 몰라 따로 알 수 있을 기회가 없었을 지도 모른다.

Presentation Layer

우선 처음 이야기를 들었던 것은 4 Layer Architecture인 Presentation Layer였다.

Presentation -> Application -> Domain -> Infra

3 Layer와 비교해서 생각할 경우

Presentation

  • Controller에 해당하는 Layer

Application

  • Service에 해당하는 Layer

Domain

  • Entity에 해당하는 Layer

Infra

  • Repository에 해당하는 Layer

사실 이야기를 듣고 관련 내용을 보다보니 점점 더 미궁으로 빠져 드는 것 같아 바로 Multi Module관련 내용을 찾아보았다.

그러면 안됬다.

Multi Module 관련 자료를 찾아보다 이해가 되었기 때문에 같이 설명하는 방향으로 진행하도록 하겠다.

Ref List

DDD 계층 구조
계층 구조 아키텍처 (표현, 응용, 도메인, 인프라스트럭처)
Presentation Layer 1. 요청 방식에 따른 Variation

Multi Module

Ref List

우아한 멀티 모듈 세미나 정리, Youtube 영상
멀티모듈 설계 이야기

Multi Module이란?

여러개의 독립적인 프로젝트를 모듈로써 사용하는 하나의 프로젝트를 말한다.

한줄로 정리하면 이렇게 될 것같다.

어째서 사용하는가?

  • 공통된 기능을 더욱 쉽게 관리하기 위해서.

사람들이 가장 많이 사용하고 있던 예시를 사용해 보겠다.

위와 같은 3개의 서버가 있다고 가정하였을 때 모두 같은 Member를 사용한다.
그런데 3개중 단 하나의 서버에서 Member가 수정되는 순간 다른 2개의 서버도 Member를 수정해줘야 하는데 가장 간단한 방식은 누구라도 쉽게 할 수 있는 복사 붙여넣기.

그런데 만약 Member 단 하나가 아닌 수십개, 수백개라면..?
실수라도 발생해서 어디서 에러가 나는지도 모르는 상황을 마주하게 되면?
생각만 해도 끔찍하다.

그래서 사람들이 생각 해낸것은 Nexus와 같은 외부 저장소를 사용하는 방식이었다.

하지만 이 방식 또한 추가적인 작업이 들어가는 상황이었다.

그래서 나온 해결 방식이 Multi Module이다.

단 하나의 Member만 수정해주면 따로 건드릴 사항이 없다! 얼마나 편한가!

자, 그럼 어떻게 구성할 것인가?

이해한 범위 내에서 작성해보았을 때 이런 모양새가 나왔다.

외부 모듈의 경우 모든 계층에서 접근이 가능하다.

설명에 들어가기 앞서 저 그림이 나오기 이전에 생각했던 방식에 대해 이야기 해보려 한다.


사실 나는 어플리케이션 계층이 로드밸런서 마냥 동작하도록 설계하는 것으로 착각하고 있었다.

위 그림과 같이 도메인 별로 Spring Boot 서버가 있고, 어플리케이션 계층을 통하여 들어오는 요청의 path를 파싱하여 그에 맞는 도메인에 http 요청을 보내고 값을 다시 내뱉는 그런 구조로 생각하고 있었다.

또한 도메인 모듈의 경우 dns를 새로이 받아 그것 또한 독립적으로 요청 처리가 가능한 그런 구조로 생각하고 있었다. 그런데 만약 이렇게 될 경우 문제가 도메인 마다 서버가 생성된다는 점과 도메인에 해당하는 기능만 처리 할 수 있다는 점과 그것을 해결하기 위해 도메인에서 다른 도메인을 참조하는 순간 공통 모듈에 넣어 처리 할 수 밖에 없다는 문제가 또 발생하여 연결의 문제가 생긴다고 판단하였다.

그렇게 되면 사실 모듈로써의 기능은 없고 독립적이지 않은가.
결국 제대로 해결할려면 단일 모듈 프로젝트와 다를바 없이 작성하게 된다.

또한 네트워크를 사용한다는 점이 맘에 걸리므로 이 부분은 localhost를 사용하는 상황에서는 괜찮을까에 대한 자료도 찾아보면 좋을 것같다.


자, 그럼 이제 본론으로 돌아오려한다.

어플리케이션 모듈

  • Sprint Boot의 컨트롤러 역할을 하게 된다.
  • 여러개가 존재한다.
  • Presentation Layout에 해당한다.
  • 이 계층에서 사용하는 모듈들을 Dependency에 추가하여 원하는 것만 사용할 수 있다.

내부 모듈

  • 시스템에 연관되어 있지만 비지니스 로직과 어플리케이션에 대하여 모른다.
  • 외부 요청에 대한 기능을 담고 있다.

도메인 모듈

  • 한 문제에 대한 영역을 담당한다.
  • Application Layer에 해당된다.
  • Domain Layer와 Infra에 해당한다.

    최대한 잘게 쪼갠다는 개념보다는 뭉텅이로 자르고 더 자를 필요가 있다 생각 될 때 자르는 방식을 채택해봐야겠다.

시스템 공통 모듈

  • Util성 모듈이다.
  • 공통적으로 사용되는 모듈들을 이곳에 정의한다.

외부 모듈

  • 시스템과 관련 없이 작동하는 모듈이다.

모듈을 모아서 상위에 존재하는 새로운 모듈을 만들 수 있다.(?)


제대로 이해한건지는 잘 모르겠지만 내일은 직접 Spring Boot로 구현해 보려 한다.

profile
상황에 맞는 기술을 떠올리고 사용할 수 있는 개발자가 되고 싶은 개발자

0개의 댓글