만드려고 하는 타이어 서비스에는 크게 두 종류의 서비스가 필요하다.
- erp-service : 타이어 재고 관리, 매입/매출 관리, 주문 내역 관리, 고객 정보 관리 등 전체적인 정보 관리 기능을 제공한다.
- client-portal : 로그인, 재고 확인 및 주문, 주문 내역 조회 등 쇼핑몰과 유사한 기능을 제공한다.
규모가 작은 서비스는 하나의 프로젝트에 기능을 다 넣으면 되겠지만, 서비스가 커지고 복잡도가 높아지면 역할과 기능 단위로 프로젝트를 분리하고 싶어지는 순간이 온다.
특히 MSA 를 적용하려면 서비스 자체를 나눠서 각각 별도로 배포해야 한다.
하지만, 서비스를 나누는 것과 별개로 각 서비스가 공통적으로 사용해야 하는 부분이 존재하는 경우가 있는데 타이어 서비스가 이런 상황이다.
"erp-service" 나 "client-portal" 양쪽 모두 타이어 관련 정보, 회원 관련 정보, 주문 및 주문 내역 등의 데이터에 접근한다.
완전히 프로젝트를 분리하면 Entity 나 Repository 등 중복되는 코드가 상당히 많이 발생하게 된다.(Entity 를 수정하려면 양쪽 프로젝트를 다 수정해야한다!)
또 Util 이나 Constant 등 공통적으로 사용하고 싶은 코드들도 있을 수 있다.
이럴 때 적용할 수 있는 게 멀티 모듈이며, 하나의 프로젝트 안에 각 서비스를 모듈화하여 동작하도록 만드는 것을 의미한다.
각 모듈 간에는 의존성이 존재하며, 공통된 모듈을 서로 다른 모듈이 의존할 수도 있다.
예를 들면 데이터 도메인 관련 코드들(Entity, Repository)을 하나의 모듈에 몰아넣고 각 비즈니스 모듈들이 이런 도메인 모듈을 의존하면 도메인 코드가 하나로 관리될 수 있다.
- 공통된 코드를 공통 모듈에 작성하고 개별 코드를 각 개별 모듈에 작성한다.
- 이렇게 하면 코드의 중복을 줄이고 코드의 관리가 더 용이해진다.
- 심지어 IDE 를 하나만 켜고 사용할 수 있다!
사실 이번에 개발할 타이어 서비스는 꼭 멀티 모듈로 나눠야만 할 정도로 규모가 있는 서비스는 아니지만, 공부도 할 겸 아래와 같이 멀티 모듈로 분리해서 개발해보려고 한다.
- tire-common
- 공통 모듈. 상수나 Util 등 공통으로 사용할 코드를 작성한다.
- spring 을 포함해 아무 의존성을 가지고 있지 않다.
- 최대한 의존성을 추가하지도, 사용하지도 않는다.
- tire-domain
- 도메인을 책임지는 모듈
- Spring Data JPA 관련 의존성을 가지고 있다.
- Entity 와 Repository 코드를 가지고 있다.
- 최대한 비즈니스 연관성을 배제한다.
- command(CUD) 이벤트는 최대한 도메인 모듈을 통해 처리한다.
- 관리 포인트를 일원화 하기 위함
- query(R) 이벤트는 공통적이고 간단한 것들만 도메인 모듈에서 처리한다.
- 각 세부 비즈니스와 연관된 복잡한 조회 로직은 각 모듈에서 처리한다. (query-dsl 등)
- tire-erp
- erp 서비스
- 전체적인 타이어 속성 및 타이어 재고 관리
- 고객 정보, 주문 정보 관리
- common, domain 모듈에 의존한다.
- tire-client
- client 포탈
- 로그인 및 회원 정보 관리
- 타이어 재고 확인 및 주문/주문 관련 조회
- common, domain 모듈에 의존한다.
향후에 관리/모니터링 기능을 가지고 있는 tire-admin 이나 배치 서비스를 위한 tire-batch 모듈을 추가해볼 계획도 있지만, 일단 지금은 이렇게 4개의 모듈로 시작해보려고 한다.
