[TIL] Spring boot 개발에 앞서 알아두면 좋은 지식

스프링부트 핵심가이드 2장 개발에 앞서 알면 좋은 기초 지식을 읽고 제가 기록하고 싶은 부분만 정리한 내용입니다.

2-1. 서버 간 통신

단일 서비스 아키텍처로 서비스를 구성한다면 서버를 업데이트하거나 유지보수할 때마다 사용을 중지시키고 해야 함.
그만큼 개발에 보수적인 입장을 취할 수 밖에 없고, 서비스 자체의 규모도 커지기 때문에 서비스를 구동하는 데에도 시간이 오래 걸림.

이러한 문제를 해결하기 위해 나온 것이 마이크로서비스 아키텍처(MSA)임. MSA는 단어 그대로 서비스 규모를 작게 나누어 구성한 아키텍처를 의미함.

독립적인 애플리케이션을 개발하게 되면 각 서비스 간에 통신을 하게 되는 경우가 발생함.
이런 상황에서의 통신을 서버 간 통신이라고 함.

서버 간 통신은 한 서버가 다른 서버에 통신을 요청하는 것을 의미하며, 한 대는 서버 / 다른 한 대는 클라이언트가 되는 구조임.

---

2-2. 스프링 부트의 동작 방식

스프링 부트에서 spring-boot-starter-web 모듈을 사용하면 기본적으로 톰캣을 사용하는 스프링 MVC 구조를 기반으로 동작함.

• 서블릿
  클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술.
  서블릿 컨테이너에서 관리하며 서블릿 인스턴스를 생성하고 관리하는 역할을 수행하는 주체로서 톰캣은 WAS의 역할과 서블릿 컨테이너의 역할을 수행하는 대표적인 컨테이너임.

• 서블릿 컨테이너의 특징은 아래와 같음.

1. 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리
2. 서블릿 객체는 싱글톤 패턴으로 관리
3. 멀티 스레딩을 지원

스프링에서는 Dispatcher Servlet이 서블릿의 역할을 수행함.
스프링은 톰켓을 임베드해서 사용하기 때문에 서블릿 컨테이너와 Dispatcher Servlet은 자동 설정된 web.xml의 설정값을 공유함.

[참고] Dispatcher Servlet의 동작

1. Dispatcher Servlet으로 요청이 들어오면 Dispatcher Servlet은 핸들러(컨트롤러) 매핑을 통해 요청 URL에 매핑된 핸들러를 탐색함.

2. 핸들러 어댑터로 컨트롤러를 호출함.

3. 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 Model And View로 응답을 가공해 반환함.

4. 뷰 형식으로 리턴하는 컨트롤러를 사용할 때에는 View Resolver를 통해 View를 받아 return함.

핸들러 매핑은 요청 정보를 기준으로 어떤 컨트롤러를 사용할 지 선정하는 인터페이스임.
핸들러 매핑 인터페이스는 여러 구현체를 가지며, 대표적인 구현체 클래스는 아래와 같음.

• BeanNameUrlHandlerMapping

1. 빈 이름을 URL로 사용하는 매핑 전략
2. 빈을 정의할 때 슬래시가 들어가면 매핑 대상이 됨.

• ControllerClassNameHandlerMapping

1. URL과 일치하는 클래스 이름을 갖는 빈을 컨트롤러로 사용하는 전략임.
2. 이름 중 Controller를 제외하고 앞부분에 작성된 suffix를 소문자로 매핑함

• SimpleUrlHandlerMapping
  - URL 패턴에 매핑된 컨트롤러를 사용하는 전략

• DefaultAnnotationHandlerMapping
  - 어노테이션으로 URL과 컨트롤러를 매핑하는 방법
  

뷰 리졸버는 뷰의 렌더링 역할을 담당하는 뷰 객체를 반환함. 하지만 지금 내가 하고 있는 프로젝트는 뷰 단을 여기서 구현 안하고 플러터를 쓰므로!
뷰 리졸버를 호출하지 않고 MessageConverter를 거쳐 JSON 형태로 변환해서 응답하는 방식으로 진행할 것임.

참고로 MessageConverter는 요청과 응답에 대해 Body 값을 변환하는 역할을 수행함.

---

2.3 레이어드 아키텍처

• 레이어드 아키텍처
  애플리케이션의 컴포넌트를 유사 관심사 기준으로 레이어로 묶어 수평적으로 구성하는 구조를 의미
  일반적으로, 레이어드 아키텍처라고 하면 3계층 또는 4계층 구성을 의미함. 이 차이는 인프라(데이터 베이스) 레이어의 추가 여부로 결정됨.

• 레이어드 아키텍처 3계층

1. 프레젠테이션 계층

• 애플리케이션의 최상단 계층으로, 클라이언트의 요청을 해석하고 응답하는 역할을 수행함.
• UI & API를 제공
• 별도의 비즈니스 로직을 포함하고 있지 않으므로 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답하는 역할만 수행

2. 비즈니스 계층

• 애플리케이션이 제공하는 기능을 정의하고 세부 작업을 수행하는 도메인 객체를 통해 업무를 위임하는 역할을 수행함.
• DDD(Domain-Driven-Design) 아키텍처에서는 비즈니스 로직에 도메인이 포함되기도 하고, 별도로 도메인 계층을 두기도 함.

3. 데이터 접근 계층

• 데이터베이스에 접근하는 일련의 작업을 수행함.

레이어드 아키텍처는 하나의 애플리케이션에도 적용되지만, 어플리케이션 간의 관계를 설명하는 데에도 사용함.

레이어드 아키텍처의 특징은 아래와 같음.

1. 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받음.
2. 각 레이어는 관심사에 따라 묶여있으며 다른 레이어의 역할을 침범하지 않음.
3. 각 레이어가 독립적으로 작성되면 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이함.

스프링 부트는 별도의 설정 없이 spring-boot-starter-web의 의존성을 사용하게 되면, 기본적으로 스프링 MVC 구조를 띠게 되며 Model-View-Controller의 레이어드 구조임.

이 떄 View, Controller는 프레젠테이션 계층 영역이며 Model은 비즈니스와 데이터 접근 계층의 영역임.
다만 해당 모델로 레이어드 아키텍처를 구현하기 위해서는 역할을 세분화해야 함.

먼저 비즈니스 계층에 서비스를 배치해 엔티티와 같은 도메인 객체의 비즈니스 로직을 조합하도록 하고, 데이터 접근 계층에는 DAO(Spring Data JPA에서는 Repository)를 배치에 도메인을 관리함.

아래는 스프링의 레이어드 아키텍처임.

• 프레젠테이션 계층
  : UI 계층이라고도 부르며, 클라이언트와의 최접점.
  클라이언트로부터 데이터와 함꼐 요청을 받고 처리 결과를 응답으로 전달하는 역할을 수행함.

• 비즈니스 계층
  : 서비스 계층이라고도 부르며 핵심 비즈니스 로직을 처리하는 영역임. 트랜잭션 처리나 유효성 검사 등의 작업도 수행함.

• 데이터 접근 계층
  : 영속 계층이라고 부름. 데이터베이스에 접근하는 작업을 수행하며 DAO라는 컴포넌트를 쓰지만 부트에서는 Repository가 이 역할을 수행하므로 해당 컴포넌트로 대체 가능.

---

2-4. 디자인 패턴

GoF (Gang of Four)

생성, 구조, 행위 패턴 3가지로 구분됨.

각 패턴의 특징과 해당 패턴에 속하는 디자인 패턴들은 아래와 같음.

1. 생성 패턴
   객체 생성에 사용되는 패턴으로 객체를 수정해도 호출부가 영향을 받지 않게 됨.

• 추상 팩토리 : 구체적인 클래스를 지정하지 않고 상황에 맞는 객체를 생성하기 위한 인터페이스를 제공하는 패턴
• 빌더 : 객체의 생서오가 표현을 분리해 객체를 생성하는 패턴
• 팩토리 메소드 : 객체 생성을 서브클래스로 분리해서 위임하는 패턴
• 싱글톤 : 한 클래스마다 인스턴스를 하나만 생성해서 인스턴스가 하나임을 보장하고 어느 곳에서 접근할 수 있게 제공하는 패턴

2. 구조 패턴
   객체를 조합해서 더 큰 구조를 만드는 패턴.

• 어댑터 : 클래스의 인터페이스를 의도하는 인터페이스로 변환하는 패턴
• 브리지 : 추상화와 구현을 분리해서 각각 독립적으로 변형케 하는 패턴
• 컴포지트 : 여러 객체로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루는 패턴
• 데코레이터 : 객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 하는 패턴
• 퍼사드 : 서브시스템의 인터페이스 집합들에 하나의 통합된 인터페이스를 제공하는 패턴
• 플라이웨이트 : 특정 클래스의 인스턴스 한 개를 가지고 여러 개의 가상 인스턴스를 제공할 떄 사용
• 프락시 : 특정 객체를 직접 참조하지 않고 해당 객체를 대행(proxy)하는 객체를 통해 접근하는 패턴

3. 행위 패턴
   객체 간의 알고리즘이나 책임 분배에 관한 패턴으로 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배함. 결합도 최소화를 고려할 필요가 있음.

• 책임 연쇄 : 요청 처리 객체를 집합으로 만들어 결합을 느슨하게 만드는 패턴
• 커맨드 : 실행될 기능을 캡슐화해서 주어진 여러 기능을 실행하도록 클래스를 설계하는 패턴
• 인터프리터 : 주어진 언어의 문법을 위한 표현 수단을 정의하고 해당 언어로 구성된 문장을 해석하는 패턴
• 이터레이터 : 내부 구조를 노출하지 않으면서 해당 객체의 집합 원소에 순차적으로 접근하는 방법을 제공하는 패턴임.
• 미디에이터 : 한 집합에 속한 객체들의 상호작용을 캡슐화하는 객체를 정의한 패턴
• 메멘토 : 객체의 상태 정보를 저장하고 필요에 따라 상태를 복원하는 패턴
• 옵저버 : 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버 목록을 객체에 등록해 상태가 변할 떄마다 메서드 등을 통해 객체가 직접 옵저버에게 통지하게 하는 디자인 패턴
• 스테이트 : 상태에 따라 객체가 행동을 변경하게 만드는 패턴
• 스트래티지 : 행동을 클래스로 캡슐화해서 동적으로 행동을 바꿀 수 있게 하는 패턴
• 탬플릿 메서드 : 일정 작업을 처리하는 부분을 서브클래스로 캡슐화해서 전체 수행 구조는 바꾸지 않으면서 특정 단계만 변경
  해서 수행하는 패턴
• 비지터 : 실제 로직을 가지고 있는 객체가 로직을 적용할 객체를 방문하며 실행하는 패턴

---

2-5. REST API

대중적으로 가장 많이 사용되는 애플리케이션 인터페이스.
클라이언트는 서버에 접근하고 자원을 조작할 수 있음.

• REST란?
  Respresentational State Transfer의 약자로, 분산 하이퍼미디어 시스템 아키텍처의 한 형식임.
  주고 받는 자원에 이름을 규정하고 URI에 명시해 HTTP 메서드를 통해 해당 자원의 상태를 주고받는 것을 의미함.

• REST API란?
  API란 Application Programming Interface의 약자로, 애플리케이션에서 제공하는 인터페이스를 의미함.
  API를 통해 서버 또는 프로그램 사이를 연결할 수 있음.
  즉, REST API는 REST 아키텍처를 따르는 시스탬 / 애플리케이션 인터페이스라고 보면 됨.
  REST 아키텍처를 구현하는 웹 서비스를 RESTful하다라고 표현함.

• REST API의 특징

1. 유니폼 인터페이스
   : 일관된 인터페이스로 REST 서버는 HTTP 표준 전송 규약을 따르기 때문에 플랫폼 및 기술에 종속되지 않고 타 언어, 플랫폼, 기술 등과 호환해 사용할 수 있음.

2. 무상태성
   : 서버에 상태 정보를 따로 보관하거나 관리하지 않는다는 의미.
   서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키 정보를 별로도 보관하지 않음. 한 클라이언트가 여러 요청을 보내든, 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리함.
   이렇게 하면 서버가 불필요한 정보를 관리하지 않으므로 비즈니스 로직의 자유도가 높고 설계가 단순함.

3. 캐시 가능성
   : REST는 HTTP 표준을 그대로 사용하므로 HTTP의 캐싱 기능을 적용할 수 있음. 응답과 요청이 모두 캐싱 가능한지 명시가 필요하며 캐싱이 가능한 경우 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용함.
   이 기능을 사용하면 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선됨.

4. 레이어 시스템
   : REST 서버는 네트워크 상의 여러 계층으로 구성됨,
   클라이언트는 서버와 연결되는 포인트만 알면 됨.

5. 클라이언트 - 서버 아키텍처
   : REST 서버는 API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계함. 이 구성은 서로에 대한 의존성을 낮추는 기능을 함.

• REST의 URL 설계 규칙

1. URI의 마지막에는 '/'를 포함하지 않음
2. 언더바(_)는 사용하지 않음. 대신 하이픈(-) 사용함.
3. URL에는 행위(동사)가 아닌 결과(명사)를 포함함. 행위는 HTTP 메서드로 표현해야 함.
4. URL는 소문자로 작성해야 함.
5. 파일의 확장자는 URI에 포함하지 않음. 파일 확장자는 Accept 헤더를 쓰는 것이 좋음.