레이어드 아키텍쳐란?

애플리케이션을 세 가지 계층으로 분리하여 만드는 설계 기법이다.

• Presentation Layer, Business Layer(Service Layer), Data Access Layer(Repository Layer) 이렇게 세 가지 레이어로 구성되어있다.

레이어드 아키텍쳐를 사용하는 이유는?

하나의 클래스가 많은 역할을 부담하지 않고, 책임을 분산하기 위해 사용한다.

• 각 계층은 명확한 역할 분담이 되어있다.

• 코드의 재사용성, 유지보수성, 확장성에 이롭다.

Presentation Layer (Controller)

클라이언트의 요청을 받고 응답하는 역할을 담당한다.

• 사용자의 요청에 따라 화면을 응답하거나, 데이터를 응답하는 API를 정의한다.

클라이언트의 요청이 컨트롤러(Presentation Layer)로 들어가고, 컨트롤러는 요청에 대한 처리를 Business Layer(Service Layer)로 전달한다.

이 후 서비스 레이어에서 처리된 결과를 다시 클라이언트에게 응답한다.

• 사용하는 어노테이션 : @Controller, @RestController

• 예시 코드
  
  컨트롤러 레이어의 예시 코드이다. 컨트롤러 레이어는 클라이언트의 요청을 받아서, 응답하는 역할만 수행하므로, 받은 요청에 대한 처리는 서비스 레이어로 넘겨주어야한다. 따라서 필드 값으로 서비스 레이어를 선언하고, 생성자 또한 서비스 레이어를 매개변수로 생성한다.

이 후 받은 요청은 DTO에 담아 서비스레이어의 handleServiceProcess기능으로 전달하고, 처리된 값을 다시 DTO에 담아 받아온 뒤, return하여 클라이언트에 응답한다.

Business Layer(Service Layer)

요청이 들어왔을 때 어떻게 처리할것인지에 관한 비지니스 로직을 수행한다.
예를 들어 클라이언트의 요청을 확인하고, 확인한 값에 조건을 적용하는 등의 로직을 담는다.

• 데이터베이스와 상호작용이 필요한 경우엔 Repository Layer에게 요청한다.

• 일반적으로 하나의 비지니스 로직은 하나의 트랜잭션으로 동작한다.
  (트랜잭션이란 일련의 작업들을 하나로 묶어 처리하는 개념으로 이해하면 쉽다.)

• 사용하는 어노테이션 : @Service

• 예시 코드
  
  서비스 레이어 또한 레포지토리 레이어에 값을 넘겨주어야하므로 필드값과 생성자에 레포지토리레이어를 넣어 선언한다.

이 후 컨트롤러에서 넘겨준 RequestDto의 값을 매개변수로 비즈니스 로직을 처리하여 레포지토리 레이어로 넘겨준다. 레포지토리 레이어에서 처리된 값을 담은 result변수를 다시 Response Dto에 담아서 컨트롤러로 반환한다.

Data Access Layer(Repository Layer)

데이터와 관련된 역할을 수행한다.
데이터베이스와 연동하여 데이터를 저장, 수정, 삭제 등의 로직을 담는다.

• 사용하는 어노테이션 : @Repository

• 예시 코드
  
  레포지토리 레이어의 예시 코드이다. 레포지토리 레이어는 데이터베이스와 관련된(CRUD)만 처리하므로, 따로 필드값이나 생성자는 생성하지 않은 모습이다.