멀티 모듈 구조
controller - service - internal/external module - repository
Controller (module-api, module-batch)
- 도메인만을 담당
Service (module-service)
- 실질적인 작동하는 하는 부분
Repository (module-core)
- DB와 연결을 담당
개발과정에서 스파게티 코드를 막게 하기위해 각각의 모듈은 서로가 하는 일을 할 수 없어야하고 알 수 없게 해야한다. 참고하던 이전의 프로젝트에서 실수가 일어난 것을 보면서 꾸준히 아키텍쳐를 바라보며 각각의 모듈이 역할에 맞게 잘 작동하는지 검증이 필요했다.
서비스 단에서는 유저 관리하는 모듈과 포인트를 관리하는 모듈을 분리 함으로써 독립적으로 서버를 띄워 scale-out을 할 수 있다.
포인트-결제 시스템같은 경우 시간에 대해 매우 예민하고 서버가 절대적으로 살아 있어야하기 때문에 독립적으로 운영을 할 필요가 있다고 느껴졌지만 현재의 프로젝트는 규모가 너무 작기 때문에 기회가 있다면 모듈분리 작업을 도전해 보고싶다.
batch 서버에서는 독립적인 하위 service단을 두고 개발을 하려고했으나 경험의 부족으로 하지 못했다.
그리고 rabbitMQ 메세지를 날릴때 LocalDateTime을 전송하지 못했는데 그 문제를 파악하기가 어려웠다. LocalDateTime 전송문제를 해결하기 위해 DB호출을 한번 더 하는것으로 해결됐지만, batch서버 특성상 주기적으로 돌아가기 때문에 DB호출을 최소화하고 싶은 욕심에 Config파일을 열심히 고쳐봤지만 실패로 돌아갔다.(데이터유효성 검증을 하기 위해 DB를 호출을 다시하는게 맞다는 것을 그 후 개발에서 앎 -> 결국 처음 개발과정이 맞았음)
결론
단일 서버 구조로 추천하는 아키텍쳐이며 모노레포형식의 서버가 늘어나게 될 경우 Controller와 Service 모듈이 많이 늘어나는 단점이 있다.
