https://chinggin.tistory.com/454
프로젝트 설계 중에 URI 설계가 필요했다.
path 부분은 자원에 대해 서술해야하는 부분으로 어떻게 서술할까 고민을 하던 도중 사내 개발 표준 문서, 현업의 Swagger를 확인해 보니 너무나 헷갈리기 시작했다. 회사에서 내준 과제는 aggregate join을 통해 특정 데이터를 조회하는 것이었다. 아무래도 aggregate join한 데이터를 쓰다보니 path상의 주 리소스가 a, b, c, ... n개의 테이블에서 조인했을 때 나오는 결과여야 하는데 이는 논리테이블의 데이터지 물리테이블의 데이터가 아니라서 새로운 이름의 주 리소스가 필요해 보였다. 하지만 사내 규칙은 SampleController의 Sample이 주 리소스로 들어가고 있었기 때문에 새로운 디렉토리가 필요했다. 애매해서 동기에게 물어보니 aggregate join을 할 때 맨 처음 식별되는 데이터(데이터 관계에서 최상위 데이터 자원)를 다루는 controller를 주 리소스로 path에 넣어야 한다고 했다. 하지만 내규에는 맞지 않아 보여서 이리저리 생각도 해보고 영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의 복습하면서 답을 찾았다.
URI 패스상의 리소스는 굳이 물리데이터와 관련되지 않아도 소스파일, 파일 등 식별이 가능한 모든 것이 자원이 될 수 있는 것이었다. 즉 Controller 소스코드 자체도 자원(Resource)이 될 수 있다는 말!
결국 새로운 디렉토리를 생성하여 aggregate join을 하여 얻은 논리데이터를 호출하는 API Controller, Service, Dto를 만들겠다고 설계하였다. 첫 MSA 관련 과제를 받고 진행을 하며 aggregate join의 문제점(AS-IS)을 느끼고 CQRS를 적용한 설계가 왜 필요한 지를 이해하게 해준 과제여서 너무 뜻깊었다.
댓글