밍쎄의 코딩공간
[스프링부트 핵심가이드] - 02. 개발에 앞서 알면 좋은 기초 지식 본문
02. 개발에 앞서 알면 좋은 기초 지식
2.1 서버 간 통신
2.2 스프링 부트의 동작 방식
2.3 레이어드 아키텍처
2.4 디자인 패턴
2.4.1 디자인 패턴의 종류
2.4.2 생성 패턴
2.4.3 구조 패턴
2.4.4 행위 패턴
2.4 REST API
2.5.1 REST란?
2.5.2 REST API 란?
2.5.3 REST의 특징
2.5.4 REST의 URL 설계 규칙
2.1 서버 간 통신
마이크로 아키텍처 (MSA : Micriservice Architecture)
: 서비스 규모를 작게 나누어 구성한 아키텍처
단일 서비스로 구성된 A포털 사이트는 내부 메서드 호출 등을 통해 원하는 자원을 가져와 사용할 수 있지만 서비스 기능별로 구분해서 B포털 사이트와 같이 독립적인 애플리케이션을 개발하게 되면 각 서비스 간에 통신해야 하는 경우가 발생한다. 예를 들면, 사용자가 블로그 기능을 사용하기 위해 로그인 서비스를 거쳐야만 하는 상황등이 있는데, 이때 상황에서의 통신을 '서버 간 통신'이라고 한다.
"서버 간 통신"은 한 서버가 다른 서버에게 통신을 요청하는 것을 의미하며, 한 대는 서버, 다른 한 대는 클라이언트가 되는 구조다.
2.2 스프링 부트의 동작 방식
스프링 부트에서 spring-boot-starter-web 모듈을 사용하면 기본적으로 톰캣을 사용하는 스프링 MVC구조를 기반으로 동작한다.
서블릿 : 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술
- 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리한다.
- 서블릿 객체는 싱글톤 패턴으로 관리된다.
- 멀티 스레딩을 지원한다.
스프링에서는 DispatcherServlet이 서블릿의 역할을 수행한다.
BeanNameUrlHandlerMapping
// 빈 이름을 URL로 사용하는 매핑 전략
// 빈을 정의할 때 슬래시 ("/")가 들어가면 매핑 대상이 됨
ControllerClassNameHandlerMapping
// URL과 일치하는 클래스 이름을 갖는 빈을 컨트롤러로 사용하는 전략
// 이름 중 Comtroller를 제외하고 앞부분에 작성된 suffix를 소문자로 매핑함
SimpleUrlhandlerMapping
// URL 패턴에 매핑된 컨트롤러를 사용하는 전력
DefaultAnnotationHandlerMapping
// 어노테이션으로 URL과 컨트롤러를 매핑하는 방법
2.3 레이어드 아키텍처
애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어를 묶어 수평적으로 구성한 구조이다.
레이어드 아키텍처는 여러 방면에서 쓰이는 개념이며, 어떻게 설계하느냐에 따라 용어와 계층의 수가 달라진다.
1. 프레젠테이션 계층
- 애플리케이션의 최상단 계층으로, 클라이언트의 요청을 해석하고 응답하는 역할
- UI나 API를 제공
- 프레젠테이션 계층은 별도의 비즈니스 로직을 포함하고 있지 않으므로 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답하는 역할만 수행
2. 비즈니스 계층
- 애플리케이션이 제공하는 기능을 정의하고 세부 작업을 수행하는 도메인 객체를 통해 업무를 위임하는 역할을 수행
- DDD(Domain-Driven-Design) 기반의 아키텍처에서는 비즈니스 로직에 도메인이 포함되기도 하고, 별도로 도메인 계층을 두기도 함
3. 데이터 접근 계층
- 데이터베이스에 접근하는 일련의 작업을 수행
▷ 레이어드 아키텍처 기반 설계 특징
- 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입 받음
- 각 레이어 관심사에 따라 묶여 있으며, 다른 레이어의 역할을 침범하지 않음
: 각 컴포넌트의 역할이 명확하므로 코드의 가독성과 기능 구현에 유리
: 코드의 확장성도 좋아짐
- 각 레이어가 독립적으로 작성되면 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이
이 책은 스프링과 관련된 레이어드 아키텍처에 초점을 맞춰 쓰였다. 스프링 부트는 별도의 설정 없이 'spring-booe-starter-web'의 의존성을 사용할 때는 기본적으로 스프링 MVC구조를 띄게 되며, 밑과 같은 레이어드 아키텍처를 이룬다.
1. 프레젠테이션 계층
- 상황에 따라 유저 인터페이스 계층이라고도 함
- 클라이언트와의 접점이 됨
- 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달하는 역할
2. 비즈니스 계층
- 상황에 따라 서비스 계층이라고도 함
- 핵심 비즈니스 로직을 구현하는 영역
- 트랜잭션 처리나 유효성 검사 등의 작업도 수행
3. 데이터 접근 계층
- 상황에 따라 영속계층이라고도 함
- 데이터베이스에 접근해야 하는 작업을 수행
2.4 디자인 패턴
소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위해 고안된 해결책이다.
2.4.1 디자인 패턴의 종류
GoF 디자인 패턴은 생성 패턴, 구조 패턴, 행위 패턴의 총 세 가지로 구분된다.
2.4.2 생성 패턴
객체 생성에 관련된 패턴입니다. 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다
1. 싱글톤 패턴(Singleton) : 클래스의 인스턴스가 하나임을 보장하고 접근할 수 있는 전역적인 접근점을 제공하는 패턴으로, 디자인 패턴의 가장 많이 알려진 패턴이다
2. 추상팩토리 패턴(Abstract Factory) : 구체적인 클래스를 지정하지 않고 관련성이 있거나, 독립적인 객체들을 생성하기 위한 인터페이스를 제공하는 패턴이다
3. 빌더 패턴(Builder) : 복학 객체의 생성과정과 표현과정을 분리시켜 동일한 생성과정에서 다양한 표현을 생성할 수 있는 패턴이다
4. 팩토리 메서드 패턴(Factory Method) : 객체를 생성하는 인터페이스를 정의하지만, 인스턴스를 만드는 클래스는 서브클래스에서 결정하도록 하는 패턴입니다. 팩토리 메서드에서는 인스턴스를 만드는 것을 서브 클래스에서 하게 된다.
5. 원형 패턴(Prototype) : 생성할 객체의 종류를 명시하는 데 원형이 되는 예시물을 이용하고 새로운 객체를 이 원형들을 복사함으로써 생성하는 패턴이다.
2.4.3 구조 패턴
클래스나 객체를 조합해 더 큰 구조를 만드는 패턴입니다. 예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 서로 다른 객체들을 묶어 새로운 기능을 제공하는 패턴이다.
1. 적응자 패턴(Adapter or Wrapper) : 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해주는 패턴이다.
2. 브리지 패턴(Bridge) : 구현부에 추상층을 분리하여 각자 독립적으로 변형할 수 있도록 하는 패턴이다.
3. 데코레이터 패턴(Decorator) : 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능확장이 필요할 때 서브클래스 대신 쓸 수 있는 대안이 될 수 있다.
4. 퍼사드 패턴(Facade) : 서브시스템에 있는 인터페이스 집합에 통합된 하나의 인터페이스를 제공한다. 서브시스템을 좀 더 쉽게 사용하기 위해 고수준의 인터페이스를 정의한다.
5. 프록시 패턴(Proxy) : 어떤 다른 객체로 접근하는 것을 통제하기 위해 그 객체의 매니저 또는 자리 채움자를 제공하는 패턴이다.
2.4.4 행위 패턴
객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴입니다. 한 객체가 혼자 수행할 수 없는 작업을 여러개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는것에 중점을 두는 방식이다.
1. 옵저버 패턴(Observer) : 객체들 사이에 1 : N 의 의존관계를 정의하여 어떤 객체의 상태가 변할 때, 의존관계에 있는 모든 객체들이 통지받고 자동으로 갱신될 수 있게 만드는 패턴이다.
2. 상태 패턴(State) : 객체의 내부 상태가 변경될 때 행동을 변경하도록 허락합니다. 객체는 자신의 클래스가 변경되는 것처럼 보이게 된다.
3. 스트레이트지 패턴(Strategy) : 동일 계열의 알고리즘들을 정의하고, 각각 캡슐화하며 이들을 상호교환 가능하도록 만드는 것이다. 알고리즘을 사용하는 사용자로부터 독립적으로 알고리즘이 변경될 수 있도록 하는 패턴이다.
4. 템플릿 패턴(Template) : 객체의 연산에서 알고리즘의 뼈대만 정의하고, 나머지는 서브클래스에서 이루어지게 하는 패턴이다.
5. 비지터 패턴(Visitor) : 객체구조를 이루는 원소에 대해 수행할 연산을 표현합니다. 방문자는 연산에 적용할 원소의 클래스를 변경하지 않고 새로운 연산을 재정의 할 수 있다.
6. 역할 사슬 패턴(Chain of Responsibility) : 요청을 처리하는 기회를 하나 이상의 객체에 부여하여 요청을 보내는 쪽과 받는 쪽의 결합을 피하는 패턴이다.
7. 커맨드 패턴(Command) : 요청을 객체로 캡슐화하여 서로 다른 사용자의 매개변수화, 요청 저장 또는 로깅, 연산의 취소를 지원하게 만드는 패턴이다.
8. 인터프리터 패턴(Interpreter) : 주어진 언어에 대해서 문법을 위한 표현수단을 정의하고, 해당 언어로 된 문장을 해석하는 해석기를 사용하는 패턴이다.
9. 이터레이터 패턴(Iterator) : 내부 표현부를 노출하지 않고 어떤 객체 집합의 원소들을 순차적으로 접근할 수 있는 방법을 제공하는 패턴이다.
10. 미디에이터 패턴(Mediator) : 한 집합에 속해있는 객체들의 상호 작용을 캡슐화하는 객체를 정의하는 패턴이다.
2.4 REST API
대중적으로 가장 많이 사용되는 애플리케이션 인터페이스이다. 이 인터페이스를 통해 클라이언트는 서버에 접근하고 자원을 조작할 수 있다.
2.5.1 REST란?
- Representational State Transfer의 약자로, 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템 아키텍처의 한 형식이다.
2.5.2 REST API 란?
Representational State Transfer Application Programming Interface의 약자로, 소프트웨어 응용 프로그램 간에 통신 및 데이터 교환을 위한 인터페이스를 나타낸다.REST API는 클라이언트와 서버 간의 상호작용을 가능하게 하며, 다양한 종류의 클라이언트 (웹 브라우저, 모바일 앱, 다른 서버 등)에서 서버의 기능과 데이터를 사용할 수 있게 해준다.
2.5.3 REST의 특징
- 유니폼 인터페이스 (Uniform Interface): REST 아키텍처는 자원을 다루는 일관된 인터페이스를 제공한다. 이러한 인터페이스는 다음으로 구성된다.
- 자원 (Resources): 웹 리소스는 URI (Uniform Resource Identifier)로 식별된다. 예를 들어, 웹사이트의 사용자 정보는 /users와 같은 형태로 표현된다.
- HTTP 메서드 (HTTP Methods): 자원에 대한 조작을 표현하기 위해 표준 HTTP 메서 (GET, POST, PUT, DELETE 등)를 사용한다. 각 메서드는 명확한 의미를 가지며, 자원의 상태를 변경하거나 데이터를 요청하는 데 사용된다. - 무상태성 (Statelessness): 서버는 각 클라이언트 요청을 독립적으로 처리하며, 이전 요청과 관련된 정보를 유지하지 않는다. 클라이언트의 상태 정보는 모두 클라이언트 측에 저장되며, 서버는 각 요청을 완전히 이해할 수 있어야 한다.
- 캐시 가능성 (Cacheability): REST는 HTTP 프로토콜을 기반으로 하므로, 웹의 기본 캐싱 메커니즘을 활용할 수 있다. 클라이언트나 중개 서버는 응답을 캐시하여 나중에 동일한 요청에 대해 중복 데이터 전송을 줄일 수 있다.|
- 레이어 시스템 (Layered System): REST 아키텍처는 여러 개의 계층으로 구성될 수 있다. 각 계층은 독립적으로 관리되며, 상호작용하는 컴포넌트 간의 결합도를 낮춘다. 이를 통해 시스템의 확장성과 유지보수성을 개선할 수 있습니다.
- 클라이언트-서버 아키텍처: REST 아키텍처에서는 클라이언트와 서버가 독립적으로 발전할 수 있는 구조를 가진다. 이는 시스템의 관리와 확장을 용이하게 만들어 준다. 클라이언트는 사용자 인터페이스와 사용자 상호작용에 집중하고, 서버는 데이터 저장과 처리에 집중할 수 있다. 이러한 특징들은 REST 아키텍처를 효율적이고 확장 가능한 웹 서비스의 기반으로 만들어줍니다.
2.5.4 REST의 URL 설계 규칙
- 명확하고 직관적인 경로
- 계층 구조 활용
- 동사보다는 명사 사용
- 동사 대신 HTTP 메서드 활용
- ID 대신 자원 이름 사용
- 슬래시(/) 사용
- 하이픈(-) 사용
- 소문자 사용
위의 규칙과 가이드라인을 준수하여 RESTful API의 URL을 설계하면, 명확하고 일관성 있게 API를 구축할 수 있다. 하지만 프로젝트의 요구 사항과 컨텍스트에 따라 유연하게 조정하여 설계하는 것도 중요하다.