패키지 구조 수정 제안 #33
Description
안녕하세요 숭피티 TF 여러분~ 백엔드 리드 숀이에요.
요새 숭피티가 꽤 인기인 거 같더라구요. 제 친구들한테도 자랑도 좀 하고 다니구 있구요. 또 생각보다 반응이 괜찮습니다.
그렇다보니 코드에 관심이 생겨서 깃허브 염탐도 좀 했어요. 훌륭하게 책임이 잘 분리되어 보기 좋더군요 히히
그렇게 재밌게 보고 있던 중에 좀 제안드리고 싶은게 생겨서 이슈를 팠어요.
반드시 해야하는 이슈는 아니구요. 참고해보고 제 제안이 프로젝트의 스타일에 부합한다면 반영해주세요~
현 패키지 구조
현 패키지 구조는 보아하니 4계층의 아키텍처이며 도메인간 응집을 위해 이렇게 분리를 해놓은 것으로 보입니다.
백엔드 팀이 다같이 표준화해보자 했던 그 구조군요.
물론 개발에 참여한게 아니라 전체적인 컨텍스트를 오해하고 있을 수도 있는데요.
보다보니까 이게 패키지 구조적으로는 응집이 좀 덜됐다고 생각이 들더라구요.
대표적인 사례가 course입니다. course와 courseTime은 서로 강하게 연결된 도메인으로 보입니다.
courseTime은 이 친구만을 위한 표현 계층이 없어요. 그렇다면 다른 도메인이 이 courseTime을 참조하는 구조로만 돌아간다고 볼 수 있겠죠.
실제로 course의 비즈니스 계층이 courseTime의 구현 계층을 가져다 쓰는 모습을 볼 수 있습니다.
사용처가 더 있는지는 모르겠습니다만 이것만 봤을 땐, 두 도메인은 매우 강결합되어 있다. -> courseTime은 course 도메인의 서브 도메인이다. 정도로 생각이 듭니다.
근데 패키지 구조상에서는 course와 courseTime은 같은 domain 패키지 안에 동등한 입장(같은 depth에 있으니까요)으로 존재하니 처음 보면 두 개념이 다른 것이라고 생각을 하게 돼요.
그래서 제안 드리는 바는:
- domain
- ...
- course
- sub // 서브 도메인용 패키지를 따로 파서 관리
- courseTime
- implement
- ...
- application
- business
- implement
와 같은 구조에요. 개념적으로 두 도메인은 주-종 관계다. 라는게 눈에 보이죠. 직접 유지보수할 때도, 먼 나중에 새로 프로젝트를 맡을 사람에게도 도움이 될 거 같아요.
나머지 표현 계층이 없는 도메인들도 마찬가지에요. 주로 호출하는 쪽을 보고, 두 도메인이 주-종 관계다. 라는걸 확인하면 합치는 거죠.
그게 아니라 여러 도메인에서 호출하는 녀석이다. 라면 common한 도메인이라는 것이겠죠?
이 경우 따로 common domain을 위한 패키지를 파야할 것 같네요.
common domain 같은 경우 4계층이 완전하지 못한 녀석들인데 이곳저곳에서 여러번 참조되는 것들이라고 분류 지으면 될 것 같아요.
도메인 모델 혹은 비슷한 녀석이 있는데, 4계층이 완전하지 못하다라는 말은 즉 독립적인 도메인으로 기능하기 어렵다는 뜻입니다.
근데 이곳 저곳에서 막 쓴다? -> 그렇다면 공용 컴포넌트로서의 성격이 강한 것들인 것 같아요. 그래서 따로 분류를 하자는 거에요.
최종적으로 제안 드리고 싶은 구조는 다음과 같아요:
...
- domain
- common // 여러 도메인에서 호출하는 공용 도메인. 조건은 4계층이 완전하지 못한 것들(=컴포넌트로서의 기능만 한다는 뜻임)
// 유저 도메인 같은 것들을 넣어서는 안 됨.
- domain1
- sub
- subdomain1
- implement // 필요에 따라 계층 구분은 플젝 사양에 맞춰서 하면 좋을 듯.
- ...// 기타 등등
- subdomain2
- ... // subdomain1과 동일
- application
- business
- implement
- etc..
- domain2
- ...// domain1과 동일
- ...
한번 쭉 생각해보시고, 우리 프로젝트 개발 맥락이랑 안 맞는 거 같다! 싶으면 과감하게 close 하셔도 좋습니다. 대신 한번정도 생각은 해보셨으면 좋겠습니다!