여러 개발자들의 개발하는 방식이 다르듯이 개발자, 도메인의 성격, 프로젝트의 형태에 따라 여러 구조들의 차이가 존재한다.
디렉토리 아키텍처 즉, 파일구조에서도 큰 차이들이 있다.
오늘은 파일구조에 대해 알아본다.
초기
작년 말 SpringBoot를 접하기 이전의 나는 어떤 폴더구조를 사용했을까?
솔직히 이전에는 폴더구조? 라는게 의미가 없었다.
자바소스코드를 분리하지도 않아 main 클래스 내부에서 필드를 선언하고, 메소드를 생성하는 알고리즘 문제를 푸는게 나의 프로그래밍이였다.
◾ MVC Architecture
2023년 우테코 프리코스를 도전하면서 자료구조라는것을 살짝 알았던 것 같다.
다른사람들의 코드를 참고하고 메일로 온 공통 피드백을 보면서 패키지를 나눠 코드들을 관리해야겠다는 생각을 하게 되었던 것 같다.
이때는 딱 정직하게 M(Model), V(View), C(Controller) 로 패키지를 나눠서
model에는 엔티티, view에는 입력을 받고 출력을 처리하는 메소드들, controller에는 핵심로직이라고 할만한 내용들을 담아서 처리했다.
2주차에는 여기에 추가로 exception 폴더까지 생성해 예외를 따로 처리하기도 했다.
이렇게 생긴 구조가 바로 mvc아키텍처이다.
MVC 장점
내가 위에서 언급한대로 각각의 역할을 분명하게 나눠서 관심사를 분리할 수 있다.
하는 역할에 따라 코드를 분리하기 때문에 작은 규모의 프로젝트에서 가독성이 좋다.
관심사와 책임을 분리할 수 있기때문에 혹여 cotroller 내부 로직이 변경되더라도 사용자에 출력을 담당하는 view 단에는 영향을 미치지 않는다.
MVC 단점
하지만 mvc의 경우 나눠야할 폴더가 많아지면 복잡성이 증가해버린다는 특징이 있다.
가독성을 위해 mvc를 적용했지만 아이러니하게 더 mvc여서 알아보기 힘든 경우가 생길 수 있다.
또, mvc 이 세단계로 파일들을 나눠야하기에 보는 사람의 관점에따라 어디로 나눠야하는지 달라질때가 있다.
◾ Layered Architecture
= 계층형 구조
다음으로 소개할 구조는 계층형 구조이다.
올해 초 오르미 부트캠프를 들으면서 접했던 구조이고, 몇몇 빠른 실력자들은 이미 Springboot 개발을 해봐서 해당 구조를 사용하고 있었다.
MVC와 비슷하게 각 계층의 역할을 분리하는 형태로 크게 Controller, Service, Repository, Entity 정도로 분리한다.
장점과 단점은 MVC와 동일하다.
적용하기 만만하고 규모가 커지면 복잡하다.
◾ Feature-based Architecture
= 기능 기반 구조
계층형 구조가 Controller끼리, Service끼리, Repo끼리 모아놓은 형태라면 기능기반구조의 경우 한가지의 공통된 도메인끼리 묶어 파일을 관리하는 형태이다.
/products
- ProductController.java
- ProductService.java
- ProductRepository.java
/orders
- OrderController.java
- OrderService.java
- OrderRepository.java
기능 기반 장점
기능별로 파일을 관리하게되면 상품이나 주문 처럼 각각의 기능단위로 개발을 할 수 있고 팀 협업과 기능 테스트에 유리하다.
기능 기반 단점
가장 큰 단점으로 코드의 중복이 있다.
비슷한 역할을 수행하지만 기능별로 파일을 나누기 때문에 코드의 중복이 발생할 가능성이 높고 이는 공통 코드관리로 해결가능하지만 코드의 증가로 이 관리 역시 어려워질 수 있다.
◾ Microservices Architecture
가장 최근 부트캠프에서는 MSA 형태의 프로젝트를 개발했다.
MSA이기때문에 다음과 같은 형태의 구조가 초반에 많이 보였다.
각각의 서비스들이 독립된 어플리케이션 단위로 개발되기 때문에 어플리케이션 아래로 계층형 구조가 붙어있는 형태이다.
데이터베이스를 따로 써야하는 등의 특징때문에 다음과 같은 구조를 띈다.
/auth-service
- /controller
- /service
- /repository
/order-service
- /controller
- /service
- /repository
기능 기반과 비슷하게 생겼지만 한 어플리케이션에서 이루어지냐, 나눠지느냐의 차이가 존재한다.
단점
단점이라기보다는 어려운 점이다.
데이터 일관성을 유지 및 관리하기 어렵고 서비스간 통신에 대해 별도로 생각해야한다. (데이터 및 외부 메소드)
◾ DDD구조
Domain-Driven-Design 구조이다.
도메인 모델을 중심으로 파일을 구조화해서 프로젝트 자체가 복잡할때 적용하기 좋다.
Aggregate, 생명주기를 중심으로 파일을 나눈다.
DDD 장점
Aggregate의 관계를 보기때문에 조금더 비즈니스로직에 집중할 수 있다.
DDD는 파일구조를 떠나 설계접근 방식 중 하나로 MSA 형태의 프로젝트에서 많이 사용된다.
DDD 단점
구조가 복잡하고 러닝커브가 높다.
구조화하는데 많은 시간과 지식의 베이스가 있어야 한다.
파일구조와 디자인패턴
파일구조는 프로젝트 구조, 디자인패턴과 함께 연결된다.
"이런것들을 지키면서 코딩해보자 !"
라던지
"이렇게하면 효율이 더 좋아!"
같은 내용들이라 구조와 장단점 정도만 알고있으면 적용하는데 어렵진 않을 것 같다.
MVC 에서 controller를 view-model로 치환한 MVVM이나 presenter로 치환한 MVP 모델들 또한 존재하니 궁금하면 링크를 타고 가보기 바란다 !
게임, 앱, 웹에 따라서도 자주 사용되는 패턴이 다르다.
참고 : 유니티-MVC, MVP, MVVM
마치며
너무많다.
앞으로도 프로젝트를 보는 시각에 따라 더 많은 방식들이 생길것이다.
프로젝트에 맞는 아키텍처를 사용해 적용하는게 중요하다고 생각한다.
다양한 환경에서의 프로젝트 경험을 해보면서 각 패턴들의 장단점을 알고 있어야 적용할때 어려움을 좀 덜 수 있을 듯 하다.
