우선 이번 프로젝트에서는 도메인 주도 개발 방식을 도입하기로 했다.
위의 블로그를 보며 개발 방법에 따른 프로젝트 구조에 대한 고찰을 시작했다.
개발 방식에는 크게 "계층형", "도메인형"으로 나눌 수 있다.
계층형은 가장 일반적인 디렉토리 구조이고, Service, Repository, Domain 등의 계층으로 나누어 개발
도메인형의 경우, "기술적인 구조 보다는 조금 더 사용자의 입장에서, 도메인 단위로 묶어서 구조를 가져가는 것
이 정도 차이가 있다고 이해했다.
참고한 사이트들
▶ https://velog.io/@haron/Spring-Project-Structure
▶ https://velog.io/@cisxo/Spring-프로젝트-계층형-구조-vs-도메인형-구조
▶ https://cheese10yun.github.io/spring-guide-directory/
일단은 도메인형 패키지 구조로 개발하기로 결정했다.
1. 그 동안 회의 중 잠깐 잠깐 나왔던 기능 (서비스)를 혹시라도 추가하게 된다면 도메인형 구조가 유리하다
2. 우리의 데이터 베이스에 category 같은 직접 관리할 content라던가, interview에 묶여있는 서비스 & 엔티티 들이 하나의 도메인으로 묶이기 좋은 구조로 짜여져 있다.
위의 두가지 이유로 도메인형 구조로 짜는 것에 마음이 기울었다.
하지만 고민이 많았다. 도메인 단위로 자른다? 서비스 단위로 크게 보고 엔티티들을 분류하면 되는건가?
그래서 우선 글을 읽으며 대충 머리 속으로 간단하게, 도메인에 따라서 데이터 베이스 테이블을 분류해보았다.
대충 정한 후 같이 하는 프론트 팀원 분께 의견을 구해봤다. 여러 허점을 발견했고, 이 뒤로도 이야기를 좀 더 나누어 보았는데, 아직은 내가 DDD를 완벽하게 생각해내고 짤만큼의 실력이 안나온다는 것을 깨달았다.
당연히 그럴 수 밖에 없다고 생각하기도 했다.
그래서!
늘 하던대로 일단 머리 박치기로 밀어붙이고 나중에 후회하기로 했다.
앉아서 고민만해서 뭐하나 직접 겪어봐야겠다.
결론적으로 우리 프로젝트 (도메인형)구조에 대한 최종적인 나의 결정은 아래였다.
- member -> auth, profile
- 유저 서비스에 관련된 도메인
- interview -> interview, interviewQnA, InterviewCategory, interviewResult
- 인터뷰 (세션) 서비스에 관련된 도메인
- content -> category, question, position
- 컨텐츠 서비스에 관련된 도메인
- 이유는 이 content에 들어가는 데이터들이 content의 분류에 관한 것들인데, 우리가 직접 데이터를 넣어줄 생각이기 때문에 따로 관리하기 위하여 분류하였다.
- 사실 content라는 도메인 명이 적절한지에 대해서 좀 더 생각이 필요하다
- bookmark -> bookmark
- 북마크 서비스에 관련된 도메인
추후 프로젝트 진행에 따라 결로적으로 어떻게 될지 모르겠지만 하여튼 도메인형 구조에 대한 짧은 나지막한 고민이였다. 😫
'Project > chatty-potato' 카테고리의 다른 글
| [Backend] 스프링 첫 시작 (1) | 2024.09.05 |
|---|
