[백엔드 아키텍처] 계층 구조 vs 도메인 구조에 대한 고민

1. 글을 쓰게 된 계기

 

프로젝트를 진행하면서 백엔드 서버 구축 업무를 맡았고, 당연하게 아키텍처에 대한 고민이 생겼음.

 

어떤 식으로 아키텍쳐 구조를 만들어야 개발하는 입장에서도 접근하기 쉽고

 

추후 유지보수에서 프로세스를 파악하기 쉬울까... 하는 생각과 행동에 대한 정리를 해보겠음.

 

# 잠깐! 계층 구조와 도메인 구조의 장단점 알고가기

1. 계층 구조
 * 장점
 - 패키지 구조만 보고 전체적인 구조를 파악하기 쉽기 때문에 작은 프로젝트나 도메인 개수가 적을 때 사용
 - 예를 들어 서비스 로직에 대한 기능 수정이 있을 땐 서비스 패키지만 확인하면 됨. > 해당되는 패키지만 확인

* 단점
 - 한 패키지 안의 클래스 파일들이 많이 모이게 되어 복잡해지고 관리하기 힘들어짐.
 - 추후 기능 수정으로 인한 모듈 단위로 분리하는데 어려움이 있음. 
 - 도메인별 응집도가 낮음.

2. 도메인 구조
 * 장점
 - 도메인 별로 패키지를 분리하여 계층형 방식보다 관리가 직관적임.
 - 각각의 도메인들은 서로를 의존하는 코드가 없도록 설계하기 적합해서 코드의 재활용성이 향상됨.
 - 모듈 단위로 분리하기가 계층 구조보다 쉬움.

 * 단점
 - 애플리케이션의 전체적인 흐름을 파악하기 힘듦.
 - 개발자마다 도메인에 대한 기준이 다르기 때문에 패키지 구조를 나누는 기준이 애매하고 예상과 다른 패키지에 존재할 수 있음.

 

2. 기존 프로젝트 문제점 인식

 

이번 프로젝트는 맨땅에서 시작하는 것이 아닌 기존 프로젝트를 참고하여 개발하였음.

 

기존 프로젝트는 메뉴 별 계층 구조를 사용하고 있었고 

 

개발을 해보니 도메인이 많으면 많을수록 복잡해져 시스템 파악이 어려웠음.

 

그리고 컨트롤러에서 서비스 로직이나 vo와 같은 다른 클래스를 찾는 데도 시간이 오래 걸리는 단점들이 보였음.

기존 디렉토리 구조

 

3. 문제점 개선을 위한 해결 방안

 

위와 같은 문제점을 해결하기 위해 도메인 구조로 디렉터리 구조를 변경함.

 

단, 메뉴별 도메인 구조로 아키텍처를 구축함.

 

이유는 도메인이 각 메뉴에 종속되어 있고 도메인 구조가 프로세스를 이해하는데 빠르다고 판단하였음.

변경된 디렉토리 구조

 

4. 생각 및 느낀 점

 

백엔드 아키텍처에 대해서 고민해 본 게 처음은 아니지만 이렇게 직접 찾아보고 장단점을 정리해 본 적은 없는 것 같음.

 

하지만 분명 디렉터리 구조는 추후 유지보수뿐만 아니라 당장 개발할 때도 연관이 있는 중요한 부분이라는 것을 한번 더 깨닫게 되었음.

 

확실히 계층 구조는 클래스 파일이 많아질수록 관리가 어렵기 때문에 도메인 구조가 웬만해서는 낫지 않을까 생각함.(하지만 정답은 없고 프로젝트마다 다르다는 것을 인지!)

 

작은 프로젝트라면 어떤 구조던지 크게 문제는 없겠지만 시스템이 커지고 서비스 로직이 많아질수록 백엔드 아키텍처에 대한 중요성이 부각이 될 수밖에 없다는 것을 느꼈음. 이상 끝.👍

 

📢참고사이트

https://velog.io/@jmjmjmz732002/Springboot-directory-%EA%B5%AC%EC%A1%B0-%EA%B3%84%EC%B8%B5%ED%98%95%EA%B3%BC-%EB%8F%84%EB%A9%94%EC%9D%B8%ED%98%95

[Springboot] directory 구조 : 계층형과 도메인형

https://velog.io/@syb0228/%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%ED%8C%A8%ED%82%A4%EC%A7%80-%EA%B5%AC%EC%A1%B0-%EA%B3%84%EC%B8%B5%ED%98%95-vs-%EB%8F%84%EB%A9%94%EC%9D%B8%ED%98%95

아키텍처 패키지 구조 : 계층형 vs 도메인형