제가 이해한 것을 바탕으로 레이어드 아키텍쳐를 알아보겠습니다.
-
총 3개의 레이어
- persistant layer(model)
- business layer(service)
- presentation layer(view)
-
persistance layer(model)
데이터베이스에서 쿼리를 직접 가져오는 단계-
범용적일 수록 좋다.
예를 들어 유저정보를 가져올때,
id,email과 같은 input에 관계없이 원하는 유저를 가져와야 나중에 service에서 사용할 때 재사용성 높게 사용할 수 있다.Django와 비교를 하자면 User.objects.get() 같은 함수를 직접 만드는 것이라고 생각하자.
-
에러처리는 최소화 해준다.
이부분에서 처음에 어디까지 에러처리를 해야하나 고민을 많이 했다.persistance layer에서는 최대한 단순하게 가는 것이 좋다고 하였다.
불필요한 데이터를 business layer에 주어도 business layer에서 알아서 잘 처리하겠거니하고 성능에 큰 무리가 가지 않는한 가지고 있는 모든 정보를 전달한다고 생각하자.
-
예시
로그인에서 persistance layer는
id를 인자로 주었을 때 해당 유저에 대한 쿼리만 반환하면된다. 비밀번호 일치 여부, 탈퇴여부, 로그인 승인 여부등은 bussiness layer에게 넘긴다.
-
-
business layer(seviece)
로직에 필요한 부분만 생각하면된다. request나 쿼리 스트링은 상위레이어에서 처리 잘했겠거니하고 로직에만 집중한다.-
예시
로그인 기능을 구현할 때 필요한 인자는아이디,비밀번호를 받아 DB에 해당 유저를 요청하고 로그인이 정상적이면 토큰을 발행하고, 아니면 에러처리를 해준다.
HTTP나 WEB에 대해서는 생각하지 않아도 된다.모델(persitance layer)에 무엇을 주어야 하는지만 고민하자.
-
-
presentation layer(view)
이부분과 business layer의 구분이 어려웠다.기업협업 선생님께 여쭤봤을 때 client의 request를 서비스 로직에 맞게 변형하고, 서비스 로직의 결과를 http response에 맞게 변형하는 역할이라고 이해하면 된다고 하셨다.
request를 받아서 service에 맞게 인자를 넘겨주고 service에서 받아온 return을 HttpResponce에 맞게 변형만 시켜준다고 생각하자.
-
예시
예를 들어 소셜로그인을 구현한다고 했을 때 기존의 장고 View에서는 로그인 관련하여 중복되는 부분들이 많았다.이런 부분들을 공통된 '로그인'서비스를 business layer에 두고 view에서는 카카오든, 구글이든 모든 통신 관련된 부분을 처리한뒤 input만 '로그인'서비스에 맞게 넘겨주면 된다.
-
마치며
무튼 Layered Architecture는 다양한 고객의 요구사항이 있을 때 최소한의 수정으로 대응하려고 만들어진 것 같다.
persistance layer는 데이터베이스 전달에만 집중하고,
business layer는 로직 구현에만 집중하고,
presentation layer는 웹 통신에만 집중한다.
메인이 되는 business layer가 집중할 수 있도록 다른 layer들이 재미없는 부분을 맡은 느낌이다.
이렇게 업무를 분리하여 재사용성과 확장성 및 가독성을 높이는 방식이라 조심스럽게 생각해본다.
이제 코드짜러 가면된다.
