레이어드 아키텍처
레이어드 아키텍처(Layered Architecture)란 애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조를 의미, 여러 방면에서 쓰이는 개념이며, 어떻게 설계하느냐에 따라 용어와 계층의 수가 달라짐
일반적으로 레이어드 아키텍처라고 하면 3계층 또는 4계층 구성을 의미. 이 차이는 인프라(데이터 베이스) 레이어의 추가 여부로 결정
일반적인 레이어드 아키텍처 각 계층 구분
- 프레젠테이션 계층(Presentation Layer)
- 애플리케이션의 최상단 계층으로, 클라이언트의 요청을 해석하고 응답하는 역할
- UI나 API를 제공
- 프레젠테이션 계층은 별도의 로직(프로그램을 만들 때의 논리적인 흐름)을 포함하고 있지 않으므로 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답하는 역할만 수행
- 비즈니스 계층(Business Layer)
- 애플리케이션이 제공하는 기능을 정의하고 세부 작업을 수행하는 도메인 객체를 통해 업무를 위임하는 역할을 수행
- DDD(Domain-Driven Design) 기반의 아키텍처에서는 비즈니스 로직에 도메인이 포함되기도 하고, 별도로 도메인 계층을 두기도 함
- 데이터 접근 계층(Data Access Layer)
- 데이터베이스에 접근하는 일련의 작업을 수행
레이어드 아키텍처는 하나의 애플리케이션에도 적용되지만 애플리케이션 간의 관계를 설명하는 데도 사용.
레이어드 아키텍처 기반 설계의 특징
- 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받는다.
- 각 레이어는 관심사에 따라 묶여 있으며, 다른 레이어의 역할을 침범하지 않는다.
- 각 컴포넌트의 역할이 명확하므로 코드의 가독성과 기능 구현에 유리
- 코드의 확장성도 좋아진다 - 각 레이어가 독립적으로 작성되면 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이
스프링 부트는 별도의 설정 없이 spring-boot-starter-web의 의존성을 사용할 떄는 기본적으로 스프링 MVC 구조를 띠게 되며, 대체로 아래 사진과 같은 레이어드 아키텍처를 이룬다.
스프링의 레이어드 아키텍처
spring MVC는 Model-View-Controller의 구조로 View와 Controller는 프레젠테이션의 계층 영역이며, Model은 비즈니스와 데이터 접근 계층의 영역으로 구분할 수 있음. 다만 스프링 MVC 모델로 레이어드 아키텍처를 구현하기 위해서는 역할을 세분화함. 비즈니스 계층에 서비스를 배치해 엔티티와 같은 도메인 객체의 비즈니스 로직을 조합하도록 하고 데이터 접근 계층에는 DAO(Spring Data JPA에서는 Repositor)를 배치해 도메인을 관리
스프링의 레이어드 아키텍처 각 계층 역할
- 프레젠테이션 계층
- 상황에 따라 유저 인터페이스(UI; User Interface)계층이라고도 함
- 클라이언트와의 접점이 됨
- 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달하는 역할
- 비즈니스 계층
- 상황에 따라 서비스(Service)계층이라고도 함
- 핵심 비즈니스 로직을 구현하는 영역
- 트랜잭션 처리나 유효성 검사 등의 작업도 수행
- 데이터 접근 계층
- 상황에 따라 영속(Persistance) 계층이라고도 함
- 데이터베이스에 접근해야 하는 작업을 수행
- DAO라는 컴포넌트를 표현했지만 Spring Data JPA에서는 DAO 역할을 리포지토리가 수행하기 때문에 리포지토리로 대체할 수 있다.
레이어드 아키텍처는 일반적인 계층 구조를 기반으로 필요에 따라 조금씩 변형해 사용. 가장 중요한 부분은 비즈니스 계층 영역인데, 비즈니스 로직을 어디서 담당할지 결정하고 설계하는 것이 좋다. 비즈니스 로직은 도메인 계층에서 담당하는 것이 일반적.
스프링에서 JPA를 사용하면 @Entity를 정의한 클래스가 도메인 객체가 되며, 이곳에서 비즈니스 로직을 설계하는 게 좋음.
디자인 패턴
디자인 패턴(Design Pattern)은 소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위해 고안된 해결책. 디자인 패턴에서 '패턴'이라는 단어는 애플리케이션 개발에서 발생하는 문제는 유사한 경우가 많고 해결책도 동일하게 적용할 수 있다는 의미를 내포. 그러나 디자인 패턴이 모든 문제의 정답은 아니며, 상황에 맞는 최적 패턴을 결정해서 사용하는 것이 바람직
디자인 패턴의 종류
디자인 패턴을 구체화해서 정리한 대표적인 분류 방식으로 'GoF 디자인 패턴'이 있음.
<GoF 디자인 패턴>
GoF 디자인 패턴은 생성(Creational)패턴, 구조(Structural)패턴, 행위(Behavioral)패턴 총 세 가지로 구분
생성(Creational) 패턴
객체 생성에 사용되는 패턴으로, 객체를 수정해도 호출부가 영향을 받지 않게 함
-
추상 팩토리(Abstract Factory) : 구체적인 클래스를 지정하지 않고 상황에 맞는 객체를 생성하기 위한 인터페이스를 제공하는 패턴
-
빌더(Builder) : 객체의 생성과 표현을 분리해 객체를 생성하는 패턴
-
팩토리 메서드(Factory Method) : 객체 생성을 서브클래스로 분리해서 위임하는 패턴
-
프로토타입(Prototype) : 원본 객체를 복사해 객체를 생성하는 패턴
-
싱글톤(Sigleton) : 한 클래스마다 인스턴스를 하나만 생성해서 인스턴스가 하나임을 보장하고 어느 곳에서도 접근할 수 있게 제공하는 패턴
인스턴스 : 일반적으로 실행 중인 임의의 프로세스, 클래스의 현재 생성된 오브젝트를 가리킨다. 객체(오브젝트)의 인스턴스는 데이터베이스나 SGA, 백그라운드 프로세스등 광범위한 컴퓨터시스템 자원의 접근에 할당된 물리 메모리의 일부를 가리킨다.
구조(Structural) 패턴
객체를 조합해서 더 큰 구조를 만드는 패턴
- 어댑터(Adapter) : 클래스의 인터페이스를 의도하는 인터페이스로 변환하는 패턴
- 브리지(Bridge) : 추상화와 구현을 분리해서 각각 독립적으로 변형케 하는 패턴
- 컴포지트(Composite) : 여러 객체로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루는 패턴
- 데코레이터(Decorator) : 객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 하는 패턴
- 퍼사드(Facade) : 서브시스템의 인터페이스 집합들에 하나의 통합된 인터페이스를 제공하는 패턴
- 플라이웨이트(Flyweight) : 특정 클래스의 인스턴스 한 개를 가지고 여러 개의 '가상 인스턴스'를 제공할 때 사용하는 패턴
- 프락시(Praxy) : 특정 객체를 직접 참조하지 않고 해당 객체를 대행(프락시)하는 객체를 통해 접근하는 패턴
행위(Behavioral) 패턴
객체 간의 알고리즘이나 책임 분배에 관한 패턴, 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배. 결합도 최소화를 고려할 필요가 있음
-
책임 연쇄(Chain of Reposibility) : 요청 처리 객체를 집합으로 만들어 결합을 느슨하게 만드는 패턴
-
커맨드(Conmmand) : 실행될 기능을 캡슐화해서 주어진 여러 기능을 실행하도록 클래스를 설게하는 패턴
-
인터프리터(Interpreter) : 주어진 언어의 문법을 위한 표현 수단을 정의하고 해당 언어로 구성된 문장을 해석하는 패턴
-
이터레이터(Iterator) : 내부 구조를 노출하지 않으면서 해당 객체의 집합 원소에 순차적으로 접근하는 방법을 제공하는 패턴
-
미디에이터(Mediator) : 한 집합에 속한 객체들의 상호작용을 캡슐화하는 객체를 정의한 패턴
-
메멘토(Memento) : 한 집합에 속한 객체들의 상호작용을 캡슐화하는 객체를 정의한 패턴
-
옵저버(Observer) : 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버 목록을 객체에 등록해 상태가 변할 때마다 메서드 등을 통해 객체가 직접 옵저버에게 통지하게 하는 디자인 패턴
-
스테이트(State) : 상태에 따라 객체가 행동을 변경하게 하는 패턴
-
스트래티지(Strategy) : 행동을 클래스로 캡슐화해서 동적으로 행동을 바꿀 수 있게 하는 패턴
-
템플릿 메서드(Template Method) : 일정 작업을 처리하는 부분을 서브클래스로 캡슐화해서 전체 수행 구조는 바꾸지 않으면서 특정 단계만 변경해서 수행하는 패턴
-
비지터(Visitor) : 실제 로직을 가지고 있는 객체(visitor)가 로직을 적용할 객체(element)를 방문하여 실행하는 패턴
REST API
Rest API는 대중적으로 가장 많이 사용되는 애플리케이션 인터페이스이다
REST란?
'Representatinal State Transfer'의 약자로, 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템 아키텍처의 한 형식. 주고받는 자원(Resource)에 이름을 규정하고 URI에 명시해 HTTP 메서드(GET, POST, PUT, DELETE)를 통해 해당 자원의 상태를 주고 받는 것을 의미
REST API란?
먼저 API는 'Application Programming Interface'의 약자로, 애플리케이션에서 제공하는 인터페이스를 의미. API를 통해 서버 또는 프로그램 사이를 연결할 수 있다. 즉, REST API는 REST 아키텍처를 따르는 시스템/애플리케이션 인터페이스라고 볼 수 있다. REST 아키텍처를 구현하는 웹 서비스를 'RESTful하다'라고 표현
인터페이스(interface)는 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면이다. 즉, 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템을 의미한다. 컴퓨팅에서 컴퓨터 시스템끼리 정보를 교환하는 공유 경계
REST의 특징
유니폼 인터페이스
유니폼 인터페이스란 '일관된 인터페이스'를 의미. 즉, REST 서버는 HTTP 표준 전송 규약을 따르기 때문에 어떤 프로그래밍 언어로 만들어졌느냐와 상관없이 플랫폼 및 기술에 종속되지 않고 타 언어, 플랫폼, 기술 등과 호환해 사용할 수 있다는 것을 의미
무상태성
REST는 '무상태성(stateless)'이라는 특징을 가짐. 무상태성이란 서버에 상태 정보를 따로 보관하거나 관리하지 않는다는 의미. 서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키 정보를 별도 보관하지 않음. 그렇기 때문에 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리. 이렇게 구성된 서비스는 서버가 불필요한 정보를 관리하지 않으므로 비즈니스 로직의 자유도가 높고 설계가 단순
캐시 가능성
REST는 HTTP 표준을 그대로 사용하므로 HTTP의 캐싱 기능을 적용할 수 있다. 이 기능을 이용하기 위해서는 응답과 요청이 모두 캐싱 가능한지(Casheable) 명시가 필요하며, 캐싱이 가능한 경우 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용. 이 기능을 사용하면 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선
레이어 시스템
REST 서버는 네트워크 상의 여러 계층으로 구성될 수 있음(Layered System). 그러나 서버의 복잡도와 관계없이 클라이언트는 서버와 연결되는 포인트만 알면 됨.
클라이언트-서버 아키텍처
REST 서버는 API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계. 이 구성은 서로에 대한 의존성을 낮추는 기능을 한다.
REST의 URI 설계 규칙
URL 규칙
- URI의 마지막에는 '/'를 포함하지 않는다.
- 옳은 예) http://localhost.com/product
- 잘못된 예) http://localhost.com/product/
- 언더바(_)는 사용하지 않는다. 대신 하이픈(-)을 사용
- 하이픈은 리소스의 이름이 길어지면 사용
- 옳은 예) http://localhost.com/provider-company-name
- 잘못된 예) http://localhost.com/provider_company_name
- URL에는 행위(동사)가 아닌 결과(명사)를 포함
- 옳은 예) http://localhost.com/product/123
- 잘못된 예) http://localhost.com/delete-product/123
- 행위는 HTTP 메서드로 표현할 수 있어야 함
- URI는 소문자로 작성
- URI 리소스 경로에는 대문자 사용을 피하는 것이 좋음
- 일부 웹 서버의 운영체제는 리소스 경로 부분의 대소문자를 다른 문자로 인식하기 때문. 이러한 이유로 RFC 3986은 URI 문법 형식을 정의하고 있는데, 호스트의 구성요소를 제외하고 URI의 대소문자를 구분해서 정의하고 있음
- 파일의 확장자는 URI에 포함하지 않음.
- HTTP에서 제공하는 Accept 헤더를 사용하는 것이 좋음
