Definition
- 계층화 패턴이라고 불리며, 역할에 따라 코드를 독립된 모듈로 나누어서 구성하는 방식
- Backend API 구현 간에 널리 쓰이는 패턴
- 3가지 계층으로 분리되는 구조 - Presentation Layer(View/Router/Controller), Business Layer(Service), Persistence Layer(Model)
명령 체계 - 단방향 의존성
- Order : View -> Route -> Controller -> Service -> Model
- Example
– [1] Controller은 email, password를 Route(View) 통해 받음
– [2] Controller가 Service에게 View로부터 HTTP Request 들어온 걸로 하고싶은 로직을 수행하라고 명령
– [3] Service는 토큰, 회원가입시 데이터 생성 등의 로직을 처리하고 Model에 명령
– [4] Model(Database)에선 서비스를 위해 필요한 데이터 입력/불러오기/수정/삭제 수행
– [5] Service는 Model이 맡은 일을 처리한 후 최종 결과를 Controller에게 전달
Layer Definition
- Controller : View(유저)와 직접적으로 맞닿는 부분으로서, 백엔드 API의 엔드포인트에 해당된다. Controller에서는 View로부터 전달받은 HTTP REQUEST 들을 읽어드리고 API의 EndPoint를 정의한다
- Service : 실제 시스템이 구현해야 하는 로직들이 담기는 곳이며, 필요한 데이터의 CRUD(생성, 수정, 읽기, 삭제)를 수행한다
- Model : Database(MySQL, MongoDB, etc)와 관련된 로직을 구현하며, Service 단에서 필요한 데이터의 생성, 읽기, 수정, 삭제를 실제 데이터베이스에 접근하여 처리하는 역할을 수행한다
Layered Pattern 특징
- 단방향 의존성 : 각 레이어는 오직 자기보다 하위에 있는 레이어에만 의존하여, Controller는 Service에게, Service는 Model에게만 의존하는 구조를 띈다.
- Sepration of Concerns : MVC 체계에 기반하여 각 레이어의 역할이 명확하게 분리되어 있다.
Layered Pattern 사용 이유
- 코드의 확장성: 각 레이어가 독립적이고 역할이 분명하므로 코드 확장 쉬워짐
- 코드의 재사용성: 코드의 구조를 파악하기 쉬우므로 코드 재사용성 증가
- 유지 보수: 만약 모델을 Mysql에서 mongoDB로 변경하고 싶을 경우, 오직 모델 관련 코드부분만 수정하면 되서 유지보수가 편리해진다
- 테스트 코드: 역할이 명확하게 나뉘어 있으므로 각 레이어를 위한 테스트 코드 작성이 쉬워짐 (Unit Test)
- 역할 분담: 역할이 레이어로 명확하게 분리되어 있어 각 레이어별로 팀원들 역할 분담 가능