도메인 기반 디렉토리 구조로 변경하기

1. 고민의 시작

기존의 계층형 구조의 프로젝트는 단순히 하나의 도메인에 대한 기능제공을 넘어 여러 도메인에서 다양한 기능을 제공하기 시작하면

수많은 클래스 파일과 도메인이 얽히고 설켜 유지보수에 소요되는 비용이 점점 커지게 됩니다.

특정한 기능과 연관된 기능들을 수정하기에 어디서부터 손을 대야할지 난감하기도 합니다.

그래서 도메인 기반의 디렉토리 구조로 프로젝트를 변경하며 적용하는 과정을 기록해보려고 합니다.

 

2. 디렉토리 구조

2.1 계층형 구조

 

가장 기본적이며 각 계층을 패키지로 표현하여 어플리케이션의 구조가 직관적으로 나타납니다.

하지만 프로젝트의 규모가 조금만 커져도 패키지 내의 파일수가 겉잡을수 비대해지고

특정한 도메인의 메서드를 찾기가 여간 수고롭지 않습니다.

 

2.1 도메인 기반 폴더 구조

프로젝트를 이루는 도메인을 기준으로 디렉토리를 나눕니다.

도메인 기반의 장점은 관련된 코드들이 응집해 있다는 것입니다.

반면에 프로젝트에 대한 이해도가 낮을 경우 전체적인 구조를 파악하기 어려운 점이 있습니다.

사실 계층형 구조의 프로젝트에서 계층은 명확하게 구별되어 있으므로 고민의 여지가 많지는 않다고 생각합니다.

도메인 기반 폴더 구조를 선택하면서 다음과같은 고민을 했습니다.

• 어디까지 하나의 도메인으로 묶을 것인가?
• 두 도메인에 종속적인 도메인은 어디에 소속시킬것인가?

2.2 어디까지 하나의 도메인으로 묶을 것인가?

도메인을 묶을때는 해당 도메인들의 2가지 특징을 통해 결정했습니다.

1. 확장 가능성
2. 연관성

1. 게시글 - 댓글

댓글은 현재 CRUD 기능만 제공하고 있고 신고, 좋아요 등의 기능은 제공하지 않고 있고

만약 추후 댓글에 여럭 기능들이 도입된다면 분리를 고려할 수 있겠지만 현재단계에서는 확장성이 크지는 않다고 판단했습니다.

또한 게시글과 댓글은 강한 연관성을 띄고 있기 때문에 하나의 도메인으로 묶었습니다.

 

2. 회원 - 인증

회원과 인증은 연관성은 있지만 기능적으로 분리가 가능하며

확장 가능성도 크기때문에 분리하였습니다.

 

3. 예약 - 리뷰

리뷰의 확장가능성이 크지 않아 예약과 리뷰를 하나의 도메인폴더로 묶었습니다.

 

 

3. 결론

프로젝트의 디렉토리 구조의 결정함에 있어 정답은 존재하지 않는것 같습니다.

다만 어떤 구조로 만드냐에 따라 어떠한 것을 응집시키고 나눌것이냐는 문제를 생각하게 됩니다.

어려운 문제이지만 프로젝트를 칼로 자르듯이 나누기 보다는 좀더 유연하고

현재의 상황에 맞는 해결방법을 찾는것이 키포인트라고 느꼇습니다.

현재의 프로젝트를 도메인 기반의 디렉토리로 나누며 어떠한 부분을 더 develop할지

우선순위를 정하고 생각해보는 시간이었습니다