2.1 서버 간 통신
한 서버가 다른 서버에 통신을 요청하는 것이다. 한 대는 서버, 다른 한 대는 클라이언트.
가장 많이 사용되는 방식은 HTTP/HTTPS
2.2 스프링 부트의 동작 방식
spring-boot-starter-web 모듈을 사용하면 기본적으로 톰캣을 사용하는 스프링 MVC 구조를 기반으로 동작한다.
서블릿(Servelt)은 서블릿 컨테이너에서 관리되며 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술이다.
서블릿 컨테이너는 서블릿 인스턴스를 생성하고 관리하며 톰캣은 WAS와 서블릿 컨테이너의 역할을 수행하는 대표적인 컨테이너이다.
서블릿 컨테이너의 특징
- 서블릿 갱체를 생성, 초기화, 호출, 종료하는 생명주기 관리
- 서블릿 객체는 싱글톤 패턴으로 관리
- 멀티 스레딩 지원
DispatcherServlet(이하 DS)의 동작
(1) DS로 요청(HttpServletRequest)이 들어오면 DS는 핸들러 매핑을 통해 요청 URI에 매핑된 핸들러(=controller)를 탐색한다.
(2) 핸들러 어댑터로 컨트롤러를 호출한다.
(3) 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 ModelAndView로 응답을 가공해 반환한다.
(4) 뷰 형식으로 리턴하는 컨트롤러를 사용할 때는 뷰 리졸버를 통해 뷰를 받아 리턴한다.
핸들러 매핑은 요청 정보를 기준으로 어떤 컨트롤러를 사용할지 선정하는 인터페이스로 여러 구현체를 가진다.
대포적인 구현체 클래스
- BeanNameUrlHandlerMapping
- 빈 이름을 URL로 사용하는 매핑 전략
- 빈을 정의할 때 슬래시('/')가 들어가면 매핑 대상이 됨
- ex) @Bean("/hello")
- ControllerClassNAmeHandlerMapping
- URL과 일치하는 클래스 이름을 가지는 빈을 컨트롤러로 사용하는 전략
- 이름 중 Controller를 제외하고 앞부분에 작성된 suffix를 소문자로 매핑
- SimpleUrlHandlerMapping
- URL 패턴에 매핑된 컨트롤러를 사용하는 전략
- DefaultAnnotationHandlerMapping
- 어노테이션으로 URL과 컨트롤러를 매핑하는 방법
뷰 리졸버는 뷰를 렌더링하는 뷰 객체를 반환한다.
2.3 레이어드 아키텍쳐
애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶은 수평적인 구조이다.
- 프레젠테이션 계층
- 애플리케이션의 최상단 계층
- 클라이언트의 요청 해석 및 응답
- UI나 API 제공
- 별도의 비즈니스 로직을 포함하지 않으므로 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답
- 비즈니스 계층
- 애플리케이션이 제공하는 기능 정의
- 세부 작업을 수행하는 도메인 객체를 통해 업무를 위임
- DDD(Domain-Driven Design) 기반의 이키텍처에서는 비즈니스 로직에 도메인이 포함되기도, 별도로 도메인 계층을 두기도 함
- 데이터 접근 계층
- 데이터베이스에 접근하는 일련의 작업 수행
* 각 계층은 컴포넌트로 이루어짐
어플리케이션 간의 관계를 살명하는 데도 사용 가능하다.
레이어드 아키텍처 기반 설계 특징
- 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받음
- 각 레이어는 관심사에 따라 묶여 있으며, 다른 레이어의 역할 침범 않음
- 각 컴포넌트의 역할이 명확하므로 코드 가독성과 기능 구현에 유리
- 코트의 확장성 향상
- 각 레이어가 독립적으로 작성되면 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이
- 프레젠테이션 계층
- UI 계층이라고도 함
- 클라이언트와의 접점
- 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달
- 비즈니스 계층
- Service 계층이라고도 함
- 핵짐 비즈니스 로직 구현
- 트랜잭션 처리나 유효성 검사 등의 작업 수행
- 데이터 접근 계층
- Persistence 계층이라고도 함
- 데이터베이스에 접근해야 하는 작업 수행
- Spring Data JAP에서는 DAO가 리포지토리로 대체 가능
2.4 디자인 패턴
소프트웨어를 설계할 때 자주 발생하는 문제들의 해결책이다.
2.4.1 디자인 패턴의 종류
대표적인 분류 방식으로 'GoF(Gang of Four) 디자인 패턴'이 있다.
생성(Creational) 패턴 |
구조(Structural) 패턴 | 행위(Behavioral) 패턴 |
| 추상 팩토리(Abstract Factory) 빌더(Buider) 팩토리 메서드(Factory Method) 프로토타입(Prototype) 싱글톤(Singleton) |
어댑터(Adapter) 브리지(Bridge) 컴포지트(Composite) 데코레이터(Decorator) 퍼사드(Façade) 플라이웨이트(Fwweigh') 프락시(Proxy) |
책임 연쇄(Chain ot Responsibility) 커맨드(Command) 인터프리터(nterpreter) 이터레이터(erator) 미디에이터(Mediator) 메멘토(Memenito) 옵저버(Observer) 스테이트(Slate) 스트레티지(Siralegy) 템플릿 메서드(Template Method) 비지터(Visitor) |
- 생성 패턴: 객체 생성에 사용되는 패턴으로 객체를 수정해도 호출부가 영향을 받지 않게 한다.
- 구조 패턴: 객체를 조합해서 더큰 구조를 만드는 패턴이다.
- 행위 패턴: 객체 간 알고리즘이나 책임 분배에 관한 패턴이다. 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배한다.
2.4.2 생성 패턴
추상 팩토리: 구체적인 클래스를 지정하지 않고 상황에 맞는 객체를 생성하기 위한 인터페이스를 제공하는 패턴
빌더: 객체의 생성과 표현을 분리해 객체를 생성하는 패턴
팩토리 메서드: 객체 생성을 서브클래스로 분리해서 위임하는 패턴
프로토타입: 원본 객체를 복사해 객체를 생성하는 패턴
싱글톤: 한 클래스마다 인스턴스를 하나만 생성해서 인스턴스가 하나임을 보장하고 어느 곳에서도 접근할 수 있게 제공하는 패턴
2.4.3 구조 패턴
어댑터: 클래스의 인터페이스를 의도하는 인터페이스로 변환하는 패턴
브리지: 추상화와 구헌을 분리해서 각각 독립적으로 변형케 하는 패턴
컴포지트 여러 객체로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루는 패턴
데코레이터: 객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 하는 패턴
퍼사드: 서브시스템의 인터페이스 집합들에 하나의 통합된 인터페이스를 제공하는 패턴
플라이웨이트: 특정 클래스의 인스턴스 한 개를 가지고 여러 개의 '가상 인스턴스'를 제공할 때 사용하는 패턴
프락시: 특정 객체를 직접 참조하지 않고 해당 객체를 대행(프락시)하는 객체를 통해 접근하는 패턴
2.4.4 행위 패턴
책임 연쇄: 요청 처리 객체를 집합으로 만들어 결합을 느슨하게 만드는 패턴
커맨드: 실행될 기능을 캡술화해서 주어진 여러 기능을 실행하도록 클래스를 설계하는 패턴
인터프리터: 주어진 언어의 문법을 위한 표현 수단을 정의하고 해당 언어로 구성된 문장을 해석하는 패턴
이터레이터: 내부 구조를 노출하지 않으면서 해당 객체의 집합 원소에 순차적으로 접근하는 방법을 제공하는 패턴
미디에이터: 한 집합에 속한 객체들의 싱호작용을 캡슐화히는 객체를 정의한 패턴
메멘토: 객체의 상태 정보를 저장하고 필요에 따라 상태를 복원하는 패턴
옵저버: 객체의 상태 변화를 관찰하는 옵저버 목록을 객체에 등록해 상태가 변할 때마다 메서드 등을 통해 객체가 직접 옵저버에게 통지하게 하는 디자인 패턴
스테이트: 상태에 따라 객체가 행동을 변경하게 하는 패턴
스트래티지: 행동을 클래스로 캡슐화해서 동적으로 행동을 바꿀 수 있게 하는 패턴
템플릿 메서드: 일정 작업을 처리하는 부분을 서브클래스로 캡슐화해서 전체 수행 구조는 유지하면서 특정 단계만 변경해 수행하는 패턴
비지터: 실제 로직을 가지고 있는 객체(visitor)가 로직을 적용할 객체(element)를 방문하며 실행하는 패턴
2.5 REST API
대중적으로 사용되는 애플리케이션 인터페이스이다. 이를 통해 클라이언트는 서버에 접근하고 자원을 조작할 수 있다.
2.5.1 REST란?
Representational State Transfer의 약자로, WWW와 같은 분산 하이어미디어 시스템 아키텍처의 한 형식이다.
resource에 이름을 규정하고 URI에 명시해 HTTP 메서드(GET, POST, PUT, DELETE)를 통해 해당 자원의 상태를 주고받는다.
2.5.2 REST API란?
API는 Application Programming Interface의 약자로, 애플리케이션에서 제공하는 인터페이스이다.
API를 통해 서버 또는 프로그램 사이를 연결할 수 있다.
=> REST API는 REST 아키텍처를 따르는 시스템/애플리케이션 인터페이스임
2.5.3 REST의 특징
- 유니폼 인터페이스
일관된 인터페이스. REST 서버는 HTTP 표준 전송 규약을 따르기 때문에 언어, 플랫폼, 기술 등 종속되지 않고 호환 가능하다.
- 무상태성
서버에 상태 정보를 따로 보관하거나 관리하지 않는다. 불필요한 정보를 관리하지 않으므로 설계가 단순하다.
- 캐시 가능성
HTTP 캐싱 기능을 적용할 수 있다. 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서는 성능이 개선된다.
- 레이어 시스템
REST 서버는 네트워크 상의 여러 계층으로 구성될 수 있다. 클라이언트는 서버와 연결되는 포인트만 알면 된다.
- 클라이언트-서버 아키텍쳐
REST 서버는 API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계함으로써 서로에 대한 의존성이 낮아진다.
2.5.4 REST의 URI 설계 규칙
1. URI 마지막에는 '/'를 포함하지 않는다.
2. (_) 대신 (-)을 사용한다.
3. 행위(동사)가 아닌 결과(명사)를 포함한다.
4. URI는 소문자로 작성한다.
5. 파일의 확장자는 URI에 포함하지 않는다.
from 스프링 부트 핵심 가이드: 스프링 부트를 활용한 애플리케이션 개발 실무 (장정우, 위키북스)
'Spring Boot' 카테고리의 다른 글
| 2022 GDSC Spring Study 입문 - 1주차 (1) | 2022.10.02 |
|---|---|
| 06. 데이터베이스 연동 (0) | 2022.08.11 |
| 05. API를 작성하는 다양한 방법 (0) | 2022.08.09 |
| 04. 스프링 부트 애플리케이션 개발하기 (0) | 2022.08.08 |
| 01. 스프링 부트란? (0) | 2022.08.03 |
