회의 주제
- 댓글 같은 경우 URL을 어떻게 가져가는 것이 맞을까?
- /studies/{studyId}/post/{postId}/comments
- /comments?studyId=?&PostId=?
- /comments → study ID와 Post Id는 http body에 작성
- 현재 패키지 구조로 괜찮은가
- 도메인은 최소 서비스 단위로 이루어진다고 알고 있는데 현재 이 부분을 만족하지 못하고 있음
- 현재 우리 서비스(책모이)에서는 게시글과 댓글은 스터디가 존재해야만 사용할 수 있음
- 스터디는 게시글과 댓글이 존재하지 않아도 독립적일 수 있음
회의 내용
kimyo- 1 의 경우, Study 패키지 내부에 study, post, comment가 모두 존재해야 한다고 생각
- study, post, comment가 모두 종속적이라면 study 한곳에서 관리하는게 맞다고 생각
- post와 comment를 따로 분리했을때 오히려 study에 변경포인트가 많다고 생각,
- 또한 패키지를 따로 분리했음에도 여전히 데이터가 종속적인것은 변하지 않음
- comment패키지를 study패키지와 분리할 것이라면 2와 같은 형식으로 가져가야 한다고 생각
- 하지만 그렇게 분리한다고 한다면 너무 1엔티티 1패키지의 구조에 익숙한것이 아닐까? 데이터베이스에 테이블을 추가할때마다 1패키지를 추가해야하는것일까?
kimyo의 최종의견 : 1의 패키지 구조로 가고 1로 가보면 좋겠다고 생각하긴 함
kuber- 댓글의 경우 게시글에 종속적이고 게시글은 스터디에 종속적이므로
/studies/{studyId}/post/{postId}/comments와 같은 형태가 맞다고 판단 - 종속적인 리소스의 경우 중첩된 리소스로 나타내야 URL만 보고 어떤 구조로 구성되어있는지 판단하기 쉽다고 생각
- 또한 중첩된 리소스의 경우 흐름을 파악하기 좋기 때문에 디버깅할 지점에 대한 판단도 유리하다고 생각했음
- Path Variable와 Query String을 어떨 때 사용하면 좋을지에 대해서 Path Variable은 식별에 목적을 두고 Query String은 정렬, 조건 검색과 같은 경우에 사용하는 것이 좋다라는 의견이 많았기에 현재 상황에서 studyID와 postID는 식별의 역할의 한다고 생각했음
- 데이터가 엄격하게 계층적이고 중첩이 너무 심하지 않고 관계가 너무 자주 변경되지 않는 경우 중첩 리소스를 사용하는 것을 추천한다고 해 지금 상황에 적절해보였음
- 어떤 기능에 대해 어디 패키지에 존재하는지 빠르게 확인하기 위해 현재는 테이블 기준으로 패키지를 나누는 것이 좋다고 생각했습니다.
- 현재 상황은 URL에 중첩된 리소스를 사용하는 것이 맞다는 생각이 들었습니다.
noolee- URI 에서는 리소스들간의 관계를 명시하는 것이 필요하다고 생각했어서 /studies/id/posts/id/comments 의 형식을 선호했다. 그러면서 각 리소스들은 각각의 도메인으로서 관리하는 것이 필요하다고 생각되었다.
- 하지만 현재 상황은, 중첩된 리소스 라는 관계로 인해, 하나의 도메인에서 일어나는 변경의 파급효과가 여러 패키지에까지 미치게 되는 상황이기 때문에, study 패키지에서 관리하는 것에 대해서도 고려해 보았다
결론
/comments?studyId=?&PostId=? 의 형태로 사용하기로 결정- 쿼리 스트링 형태로 사용하는 이유
- 패키지를 분리하기 때문입니다
- 패키지를 분리하는 순간 스터디와의 종속을 생각하는것은 좋은 구조가 아니라고 생각해서
- 패키지를 나눈다면 쿼리스트링
- 패키지를 기능(테이블) 단위로 나누도록 결정했습니다.
- 어떤 기능에 대해 어디 패키지에 존재하는지 빠르게 확인하기 위해 현재는 테이블 기준으로 패키지를 나누는 것이 좋다고 생각했습니다.
- DDD를 지금 설계하기에는 너무 많이 온 듯 하다
