3년차 웹 개발자에 스프링부트 아키텍처 고찰...

웹 개발을 시작한지 3년 가까이 되어가는거 같은데...

처음 1년은 vue로 프론트엔드 개발만 하다가 이후에 백엔드 개발을 본격적으로 하게 된거 같다.

경력도 경력이고 본업이 웹 개발자가 아닌지라 회사에서 사용하는 아키텍처에 대한 설명을 들을수가 없었고...

그저 감각적으로 지금까지 개발을 해온것 같다. 돌이켜 보면 질문할 생각도 못했던거 같다

그래서 최근에 공부를 해보고자 하는 마음에 이런 저런 소스들을 보게되었고 아키텍처에 대해서 고민하게 되었다.
프로젝트에 패키지 구조가 서로 다를지라도 보통 컨트롤러, 서비스, 저장소 이 3개 레이어로 구성이 되는것 같다.

 

 

컨트롤러
사용자에게 요청받아 서비스 레이어에 요청하여 다시 사용자에게 전달하는 역할을 한다.

서비스
컨트롤러에서 요청한 내용에 대한 비즈니스 로직을 처리하고 저장소 레이어와도 상호작용한다.

저장소
서비스 레이어에서 전달 받은 데이터를 데이터베이스에 영구저장한다.

이 3개에 레이어로 프로젝트를 진행했을때 제가 느낌 단점은 이렇습니다.
- 여러 사람과 협업을 할때 서비스 레이어에서 가장 많이 충돌 난다.
- 기능 자체가 많아지면 서비스 레이어에 책임이 그만큼 가중되어 유지보수하는데 많은 어려움이 존재한다.
- 서비스 레이어에 A서비스에서 사용하는 기능이 B서비스에서 중복될 경우 코드를 재활용하기가 어렵다.

이 단점을 어떻게 극복하면 좋을까 고민하다가 1개에 레이어를 더 두어 서비스 레이어에 책임을 덜어주면 어떨까하는 생각을하게 되었습니다.

문과적으로 말하자면 중앙집권체제에서 지방분권제로 변경한다라고 볼 수 있을거 같다..비유가 맞는건지는 모르겠다...

이름을 어떻게 지어야할지 고민하다가 잘 생각이 나지 않아서 일단은 서브 서비스라 지었다.

서브 서비스는 기능별로 혹은 같은 의미를 지니는 그룹을 모아놓은 서비스라고 생각하면 좋을거 같다.

예를 들어 회원 가입이라는 기능을 만들때 회원가입을 위한 프로세스가 있고 비즈니스가 존재하고 되는데..

서비스 레이어에서는 프로세스를 정의하고 서브 서비스에서는 각 기능에 맞는 비즈니스 로직이 들어간다고 보면

좋을 듯 하다.

 

위에 이미지가 잘 설명을 될지 모르겠지만 원래대로라면 서비스에 구현되어야 할 비즈니스 로직들이 서브 서비스로 옮겨지면서 프로세스가 명확하게 눈에 들어오게 된다. 또한 회원 가입중 오류가 발생했을때 프로세스가 아니라 서브 서비스에 비즈니스 로직을 수정하면 되기때문에 유지 보수 측면에서 많이 수월해질거라 기대할 수 있을거 같다.