우아한 형제들 세미나 - 우아한 멀티모듈

발표자료: https://www.slideshare.net/ssuser59a869/ss-167401606

회원 시스템

단일 모듈, 멀티 프로젝트

사람에게 의존적인 일관성으로 구성 되어 있었고, 세 프로젝트는 공유 되는 클래스들이 있었음. 내부 Nexus를 이용하고 있었고, 해당 세 프로젝트는 Nexus에서 일관성을 가지게 된다. 이렇게 구성 하는 것이 너무 복잡하고 개발 사이클이 복잡 하다.

내가 속한 환경에서도 생각해보면, 모듈 단위로 이미 구분이 잘 되어 있다. 만약 프로젝트 기준으로 나뉘게 되면, 너무 큰 범주로 작업 간 이동이 발생 하게 된다.

그런 환경은 내가 생각해도 개발 하기 쉽지 않다.

멀티 모듈, 단일 프로젝트

시스템으로 보장 되는 일관성을 얻고, 개발 사이클이 단순화 된다.

내가 속한 조직에서도 모듈 단위의 Role을 정의 해놓고, 그 규칙을 성립 해두었다. 그렇게함으로써 좋은 장점은 규칙을 위배 하지 않는 선에서 굉장히 깔끔한 구조를 가진다. 그리고, 양방향 의존성이 생기지 않도록 규칙을 가지고 있는데, 이 부분은 시간이 지날 수록 설계한 분의 엄청난 내공이 느껴진다.

MSA? 멀티 모듈?

멀티 모듈은 MSA와 비슷한 부분이 있더라.

설명을 들어보니, 결국에는 서비스의 구조를 단순화하고, 해당 구조를 조립하는 형태로 구성 하는 방식이 결국에는 유사한 모습을 띄게 된다고 생각이 들었다.

실패한 프로젝트

스파게티 코드

• common에 문제가 생기면 각 도메인의 서비스에 문제가 생기게 된다.

의존성 덩어리

• 특정 의존성이 숨겨진 의존서을 가지고 올라 가는 경우가 많다.

공통 설절

• 공통 설정은 잘 구분해서 가져가는 것이 좋다. 그렇지 않으면, 해당 설정에 영향이 적은 서비스도 영향을 크게 받는다.

모듈화란?

내가 역할을 부여 하고 해당 역할만 지닌 모듈을 끼워 맞출 수 있다면, 그게 모듈화가 아닐까? 객체 지향 중심으로 모듈을 분리 한다. 그럼 결국 역할과 책임으로 구분 지을 수 있게 된다. 모호한 부분은 어떻게 나눌까에 대한 부분이 남았다. 그래서 오픈 소스의 라이브러리를 주로 염탐을 했다. 계층 하위로 역할과 책임을 주로 구분 지어 나누고, 계층과 계층끼리 이어질 수 있다. 다만, 라이브러리와 서비스의 경우는 기준이 다르다. 그래서 결국, 직접 나누는 것으로 결정 했다.

멀티 모듈

• 시스템: 하나의 서비스와 공유 인프라가 만나 하나의 시스템을 구성 하는 단위가 된다.
• 어플리케이션 비즈니스: 요청, 응답등..
• 도메인 비즈니스: 주문 데이터 생성, 가공, 처리

내부 모듈 계층

• 외부 통신을 담당 하는 모듈을 만들자.

  • 요청, 응답 스펙 관리
  • 예외 처리 추상화 수준 통일
  • 환경별 시스템 Host, Header관리

위에서는 사실 가장 주요한 부분은 예외처리를 어떻게 추상화 할지?에 대한 부분이 중요하게 생각 하셨다고 한다.

좋은 점은 스펙 변경에 대해 변경 포인트가 단일점으로 바뀌게 된다. 사용 추적에 대한 부분도 쉬워졌다.

도메인 모듈 계층

• infrastructure 대응을 위한 모듈

  • DB관련, QueryDSL, connector관련 의존성을 가지고 있다.
• multi domain

• multi infrastructure

  • redis / DynamoDB가 둘 다 필요할 수도 있지만, 하나만 필요할 수도 있다.

독립 모듈 계층

• 시스템의 의존성이 없다.
• 오로지 필요한 외부 의존성만 있음.

공통 모듈

• Type, Util등을 정의 한다.
• 가장 큰 제약을 두었는데, 순수 Java 클래스만 작성 하도록 제한을 둠.

어플리케이션 모듈 계층

• top-down 방식으로 구성을 하게 된다.

꿀팁

• Application.java는 Project package에서 1 depth로 유지 하여, Scan 기능을 활용.

• 의존성을 숨기는 방법은 gradle에서 compile에서 implimentation으로 변경하면 된다.

  • 보호 하거나 숨겨야 할 모듈을 위의 방법으로 제약을 주면, 코드상에서 참조가 되지 않는다.