[TIL] 25/01/26, 백엔드 서비스 아키텍처

학습내용
• 레이어드 아키텍처 패턴
• REST 아키텍처 스타일
• 스프링 어노테이션
• JPA와 스프링 Data JPA

실습내용
• Model/Entity와 DTO 클래스
• Controller, Service, Persistence 클래스
• 테스팅용 REST API

 

레이어드 아키텍처 패턴은 스프링 프로젝트 내부에서 어떻게 코드를 적절히 분리하고 관리할 것이냐에 대한 것이다. 레이어드 아키텍처 패턴이 프로젝트 내부에서 어떻게 코드를 관리할 것인가에 대한 내용이라면, REST 아키텍처 스타일은 클라이언트(브라우저)가 우리 서비스를 이용하려면 어떤 형식으로 요청을 보내고 응답을 받는지에 대한 것이다. 클라이언트는 몇 개의 정해진 메서드로 우리 서비스를 이용할 예정이다. 이렇게 REST 아키텍처 스타일을 따라 설계 및 구현된 서비스를 RESTful 서비스라고 한다.

 

2.2.1 레이어드 아키텍처

레이어드 아키텍처 패턴은 애플리케이션을 구성하는 요소들을 수평으로 나눠 관리하는 것이다. 레이어로 나눈다는 것은 메서드를 클래스 또는 인터페이스로 쪼개는 것이다. 레이어에는 또 다른 특징이 있다. 레이어 사이에 계층이 있다는 점이다. 그래서 레이어는 자기보다 한 단계 하위의 레이어만 사용한다.

 

컨트롤러는 클라이언트로부터 요청을 받으면, 이를 서비스에 전달한다. 서비스는 비즈니스 로직을 처리하며, 필요한 데이터를 퍼시스턴스로부터 조회하거나 저장한다. 퍼시스턴스는 요청받은 데이터를 반환하고, 서비스는 해당 데이터를 검토 및 가공한 뒤 컨트롤러에 전달한다. 이후 컨트롤러는 최종적으로 데이터를 확인하고 추가 가공하여 클라이언트에게 응답을 반환한다.

 

서비스는 필요에 따라 다른 서비스를 호출하여 협력하기도 하며, 레이어가 많은 경우 중간 레이어를 활용하기도 한다. 그러나 기본적인 레이어드 아키텍처에서는 상위 레이어가 자신의 바로 하위 레이어만을 사용하는 것이 원칙이라고 한다.

 

2.2.2 모델, 엔티티, DTO

백엔드 개발자는 대부분의 시간을 컨트롤러, 서비스, 퍼시스턴스 로직을 구현하는 데 사용한다.

 

아무 기능 없이 데이터베이스에서 반환된 비즈니스 데이터를 담기 위한 클래스들이 있다. 그런 클래스들을 기능에 따라 엔티티, 모델, DTO(Data Transfer Obejct)등으로 부른다. 

 

모델과 엔티티

이 프로젝트에서는 모델과 엔티티를 한 클래스에서 구현한다. 따라서 모델은 비즈니스 데이터를 담는 역할과 데이터베이스의 테이블, 스키마를 표현하는 두 역할을 한다. 큰 프로젝트에서는 모델과 엔티티를 따로 구현한다.

 

@Builder
@NoArgsConstructor
@AllArgsConstructor
@Data
public class TodoEntity {
	private String id;	   // 이 오브젝트의 아이디
	private String userId; // Todo 타이틀(예: 운동하기)
	private boolean done;  // true - todo를 완료한 경우(checked)
}

@Builder

Builder는 오브젝트 생성을 위한 디자인 패턴(Refactoring Curu) 중 하나다. @Builder 어노테이션을 사용하면 Builder 클래스를 따로 개발하지 않고도 Builder 패턴을 사용해 오브젝트를 사용할 수 있다. 

⭐ 생성자와 차이점은 매개변수의 순서를 기억할 필요가 없다.

 

@NoArgsConstructor

@NoArgsConstructor 어노테이션는 매개변수가 없는 생성자를 구현한다.

 

@AllArgsConstructor

@AllArgsConstructor 어노데이션은 클래스의 모든 멤버 변수를 매개변수로 받는 생성자를 구현해 준다.

 

@Data

클래스 멤버 변수의 getter, setter, toString, equals, hashCode 메소드를 구현한다.

 

DTO

보통은 데이터를 모델 자체로 return 하지 않고 DTO로 변환해서 return 한다. 첫 번째 이유는 비즈니스 로직을 캡슐화하기 위함니다. 대부분의 비즈니스는 외부인이 자사의 데이터베이스의 스키마를 아는 것을 원치 않는다. 두 번째 이유는 클라이언트가 필요한 정보를 모델이 전부 포함하지 않는 경우가 많기 때문이다. 예로 에러 메세지가 있다. 실행 도중에 사용자가 에러가 발생하면 이 에러 메세지를 포함해야할 곳이 애매한데, 이 경우 DTO에 에러 메세지 필드를 선언하고 DTO에 포함한다.

@Builder
@NoArgsConstructor
@AllArgsConstructor
@Data
public class TodoDTO {
	private String id;
	private String title;
	private boolean done;
	
	public TodoDTO(final TodoEntity entity) {
		this.id = entity.getId();
		this.title = entity.getTitle();
		this.done = entity.isDone();
	}
}

DTO에는 userId가 없다. 스프링 시큐리티를 이용해 인증을 구현한다. 따라서 사용자가 자기 아이디를 넘겨주지 않아도 인증이 가능하다.

 

@Builder
@NoArgsConstructor
@AllArgsConstructor
@Data
public class ResponseDTO<T> {
	private String error;
	private List<T> data;
}

TodoDTO 뿐만 아니라 이후 다른 모델의 DTO도 ResponseDTO를 이용해 리턴할 수 있도록 자바 Generic을 이용했다.