2. 개발에 앞서 알면 좋은 기초 지식

1. 서버 간 통신

• MSA (Microservice Architecture)
  • 서비스 규모를 작게 나누어 구성한 아키텍처를 의미
  • 각 서비스 간에 통신을 '서버 간 통신'
    • 한 서버가 다른 서버에 통신을 요청하는 것을 의미
    • 한 대는 서버, 다른 한 대는 클라이언트가 되는 구조
    • 가장 많이 사용되는 방식은 http / https 방식

 

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

• spring-boot-starter-web 모듈을 사용하면 기본적으로 Tomcat을 사용하는 스프링 MVC 구조를 기반으로 동작
• 서블릿 : 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술
• 서블릿 컨테이너
  • 서블릿을 관리, 서블릿 인스턴스를 생성하고 관리하는 역할 수행  
  • 특징
    1. 서블릿 객체의 생명주기 관리
    2. 서블릿 객체를 싱글톤으로 관리
    3. 멀티 스레드 지원
• Spring에서는 DispatcherServlet에서 서블릿의 역할을 수행

 

 

3. 레이어드 아키텍처

• 애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조
• 보통 3계층 or 4계층
• 3계층 기준
  • 구조 : 프레젠테이션, 비즈니스, 데이터 접근
  • 프레젠테이션 계층
    1. 애플리케이션의 최상단 계층, 클라이언트의 요청을 해석하고 응답하는 역할
    2. UI나 API 제공
    3. 별도의 비즈니스 로직 x -> 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답하는 역할만 수행
  • 비즈니스 계층
    1. 애플리케이션이 제공하는 기능을 정의
    2. 세부작업을 수행하는 도메인 객체를 통해 업무를 위임하는 역할을 수행
    3. DDD기반의 아키텍처에서는 비즈니스 로직에 도메인이 포함되기도 하고, 별도로 도메인 객체를 두기도 함
  • 데이터 접근 계층
    • 데이터 베이스에 접근하는 일련의 작업을 수행
• 특징
  1. 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받음
  2. 각 레이어는 관심사에 따라 묶여 있으며, 다른 레이어의 역할을 침범하지 않음
  3. 각 레이어가 독립적으로 작성되면 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이
• 스프링의 레이어드 아키텍처
  • 프레젠테이션 계층
    1. 상황에 따라 유저 인터페이스 계층이라고도 불림
    2. 클라이언트와의 접점이 된다.
    3. 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달하는 역할
  • 비즈니스 계층
    1. 상황에 따라 서비스 계층이라고도 한다.
    2. 핵심 비즈니스 로직을 구현하는 영역
    3. 트랜잭션 처리나 유효성 검사등의 작업도 수행
  • 데이터 접근 계층
    1. 상황에 따라 영속계층이라고도 함
    2. 데이터베이스에 접근해야 하는 작업 수행

 

4. 디자인 패턴

• 소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위해 고안된 해결책
• 종류
  • 생성패턴
    1. 객체 생성에 사용되는 패턴으로, 객체를 수정해도 호출부가 영향을 받지 않게 합니다.
    2. 추상 팩토리, 빌더, 팩토리 메서드, 프로토타입, 싱글톤 등이 있다.
  • 구조 패턴
    1. 객체를 조합해서 더 큰 구조를 만드는 패턴
    2. 어댑터, 브릿지, 컴포지트, 데코레이터, 퍼사드, 플라이웨이트, 프록시 등이 있다.
  • 행위 패턴
    1. 객체 간의 알고리즘이나 책임분배에 관한 패턴
    2. 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배
    3. 결합도 최소화를 고려할 필요가 있음
    4. 책임연쇄, 커맨드, 인터프리터, 이터레이터, 미디에이터, 메멘토, 옵저버, 스테이트,
       스트레티지, 템플릿 메서드, 비지터 등이 있다.

 

5. REST API

• 대중적으로 가장 많이 사용되는 애플리케이션 인터페이스
• 이 인터페이스를 통해 클라이언트는 서버에 접근하고 자원을 조작할 수 있다.
• REST (Representational State Transfer)는 주고받는 자원에 이름을 규정, URI에 명시해 HTTP 메서드를 통해
  해당 자원의 상태를 주고받는 것을 의미
• API (Application Programming Interface)는 애플리케이션에서 제공하는 인터페이스를 의미
• 특징
  1. 유니폼 인터페이스
     • 일관된 인터페이스를 의미
     • 플랫폼 및 기술에 종속되지 않고 다 사용할 수 있다.
  2. 무상태성
     • 서버에 상태 정보를 따로 보관하거나 관리하지 않는다는 의미
     • 무상태성으로 구성된 서비스는 서버가 불필요한 정보를 관리하지 않으므로
       비즈니스 로직의 자유도가 높고 설계가 단순
  3. 캐시 가능성
     • HTTP 표준을 그대로 사용하므로 HTTP의 캐싱 기능을 적용가능
     • 캐싱을 사용하면 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선
  4. 레이어 시스템
  5. 클라이언트 - 서버 아키텍처
     • API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계
     • 서로에 대한 의존성을 낮추는 기능
• REST의 URI 설계 규칙
  1. URI의 마지막에는 '/'를 포함하지 않는다.
  2. 언더바( _ )는 사용하지 않음, 대신 하이픈( - )을 사용
  3. URL에는 행위(동사)가 아닌 결과(명사)를 포함
  4. URI는 소문자로 작성해야 함
  5. 파일의 확장자는 URI에 포함하지 않음