23-07-20 restful한 계층형 아키텍쳐의 구조

문제설명

[내배캠]node.js의 심화 주차 lv.5에서 내가 설계한 아키텍쳐의 구조가 restful하지 않다는 얘기를 들었다.

restful이란 얘기는 들어봤지만 막상 코드를 작성하면서 내가 정말 restful하게 코드를 짜려고 구상을 했었는지,

그것이 올바른 방향성인지, 내가 정말 restful한 코드가 무엇인지, restful의 개념을 알고 있었는지 되짚어 볼 수 있었다.

그리고 이번 과제를 통해서 기능 구현 뿐만 아니라 코드 자체의 짜임새를 restful하게 설계하려한다.

 

시도

예전의 시청했던 강의, 그리고 과제 리뷰 등을 통해서 restful api의 설명을 들었지만 다시한번 되짚어 보았다.

REST는 클라이언트와 서버의 통신 방식

REST API는 REST의 아키텍쳐의 스타일에 따른 api다.

RESTful API는 REST의 원칙을 따르는 웹 서비스를 구현하는 방식

서버와 클라이언트의 역할을 명확하게 분리하고 서로 독립적으로 개발 하는방식

 

즉 계층형 아키텍쳐의 형태로 기능을 구현하고자 하면 계층형 아키텍쳐의 원칙에 맞게 역할을 명확하게 분리하고 서로 독립적으로 코드를 설계해야한다는 의미다.

 

내가 짠 lv.5의 코드 구성이다.

내가 찾은 내 lv5의 코드에서 RESTful하지 못한 점은 signup과 login의 기능을 각각의 파일로 코드를 짯다는 점이다.

회원가입과 로그인은 같은 데이터베이스의 테이블을 통해서 데이터를 받아오고 각각의 기능이 서로 연계되며 유사하다는 점에서 signup과 login을 각각의 파일이 아니라 하나의 파일로 관리를 했다면 더 역할에 대한 분리가 명확했을 것 같다.

 

두 번째는 repository와 service의 역할을 분리시키지 못 했다는 점이다.

이 코드는 posts의 좋아요 기능을 구현하기 위해 짰다.

repository는 저장소에서 데이터를 찾고 추출하는 역할을 한다. 전체적인 기능 구현에 있어서는 아무문제가 없지만

데이터를 찾고 추출하며 조건문을 통해서 데이터를 가공까지 한다는 것은 역할의 분리 및 독립적인 관계을 생성함에 있어서 아무런 도움이 되지 않는다.

 

만약에 RESTful하게 코드를 작성하려 했다면 repository는 정확한 데이터를 찾고 보내주는 역할에만 충실하게 코드를 작성하고 다른 조건문은 service 쪽에서 담당하게 해야했다.

 

해결

이번 팀 프로젝트에서 코드를 설계할 때 각 테이블을 참조하는 코드들을 모아두는 방식을 사용했다.

user,store,review,product,order의 테이블을 사용하는 코드들을 따로 모아두는 방식이다.

기존의 signup, login 등의 각각의 기능별로 나누지 않았다.

 

그리고 이번에는 철저하게 controller/service/repository의 기능에 맞게 코드를 작성했다.

controller 부분은 데이터를 주고 받는 것에 집중했고

service 부분은 구현하고자 하는 기능의 조건을 설정하는데 집중했고

repository는 서비스에서 요청한 데이터를 정확하게 전달하는데 집중했다.

 

알게된 점

RESTful한 코드가 어떤 것인지 어떻게 하면 RESTful한 코드설계가 되는 것인지 생각해 볼 수있었다.

controller/service/repository의 기능에 대해서 좀 더 잘 이해할 수 있게 되었다.