1. express에서 썼던 controller - service 패턴

• express를 사용하면서는, model - controller - service 패턴에 따른 작업을 주로 하였다. 각 계층의 역할은 다음과 같다.
  model = DB 연결과 관련된 내용
  controller = request와 response의 처리
  service = 비즈니스 로직/ DB와 관련된 내용
• 이 방식에 controller는 비즈니스로직 + request와 response 처리에 집중하는 것, service는 DB source에 접근하는 것에 집중하는 것처럼 역할과 책임을 구분하였으나, 사실 두 계층만으로 request/response 처리 - 비즈니스 로직 - DB query를 분담하려니, controller와 service 각각에서 코드량이 매우 많았다. 아울러, serivce에서도 비즈니스 로직에 해당하는 코드들이 많았다.
• 즉, 나름의 역할과 책임을 분리하긴 했으나, 어딘가 모호한 지점이 있는 것이다.

2. nest의 3 layered architecture pattern, repository 계층 추가

• nest를 사용하면서, 새로운 패턴을 접하게 되었는데, 구성은 model - controller - service - repository로 되어있다. 각 계층의 역할은 다음과 같다.

• repository는 service와 마찬가지로 provider 개념에 해당하므로, 각 기능 모듈의 provider에 repository도 삽입해주어야만 한다.
  model = DB 연결
  controller = request, response 제어 및 처리
  service = 비즈니스 로직
  repository = DB Query

• 이 계층의 장점은 repository라는 계층을 이용해서, 각 계층별 역할과 책임을 더욱 명확하게 했다는 것이다. 이의 이점은 다음과 같다고 생각한다.
  1) DB Query와 비즈니스 로직을 분리함으로써, 여러 DB를 사용하는 상황, DB를 변경하는 상황에서 개별 service들을 모두 변경할 것 없이, repository만 변경하면 된다.
  2) 즉, 각 계층들은 본인의 역할과 책임에 더 충실할 수 있으며, 이는 곧 코드의 가독성과 재사용성을 극대화시킨다.

3. 구조 예시

cats
- dto
- cats.controller.ts
- cats.schema.ts
- cats.service.ts
- cats.repository.ts
- cats.module.ts