책너두 (도메인 주도 설계로 시작하는 마이크로서비스 개발) 18일차 (~156p)

요약

• 5장. 마이크로서비스 설계 나머지 부분에 대해 이해함.
  • 마이크로서비스 상세 설게
    • 프런트엔드 모델링
    • 백엔드 모델링
      • API 설계

메모

5.5 마이크로서비스 상세설계

• 마이크로서비스 상세 설계 단계에서는 서비스가 프런트엔드와 백엔드로 분리되어 개발됨.
  • 각 영역은 스프린트 동안 개발되며, CI/CD 활동을 통해 통합되고 배포됨.
  • 프런트엔드 서비스의 설계와 개발, 그리고 백엔드 서비스의 모델링과 개발이 이루어지는데, 이 책에서는 도메인 중심 설계가 가능한 백엔드에 초점을 맞춰 설명함.

5.5.1 프런트엔드 모델링

• 웹과 모바일 기술의 발전으로 사용자 경험에 중점을 둔 UI 기술과 개념이 등장하였음.
  • 이를 지원하는 프런트엔드 프레임워크들이 다양하게 등장했으며, 앵귤러(Angular), 리액트(React), 뷰(Vue.js) 등이 이에 해당함.
  • 이들은 모두 사용자 경험을 중요시하는 '싱글 페이지 애플리케이션(Single-Page Application, SPA)'를 지원함.
  • 프런트엔드에서 처리해야 할 작업이 점차 많아지고 중요해진 만큼, 프런트엔드 영역의 모노리스 구조를 분리하는 마이크로 프런트엔드 등의 패턴이 등장하였음.
  • 이 책에서는 프런트엔드 설계 관점에서 어떤 절차와 준비가 필요한지에 대해서만 간략히 살펴볼 예정임.

프런트 아키텍처 정의

• 사용자 요구에 맞는 프런트엔드 아키텍처를 정의하는 것이 중요함.
• B2C 시스템에서는 모바일과 웹 채널을 모두 고려하여 사용자 경험에 민감한 반응형 UI를 지향하는 경향이 있음.
  • 이를 지원하기 위해 리액트와 뷰와 같은 프런트엔드 프레임워크가 많이 사용되고 있으며, 이들은 컴포넌트 구조의 재사용 가능한 구조를 지원하고, 마이크로 프런트엔드 패턴을 적용할 수도 있음.
  • 프런트엔드 프레임워크가 결정되면, 스파이크 솔루션을 통해 아키텍처가 사용자 요구를 만족하는지 검토해야 함.
• 프런트엔드 아키텍처를 수립할 때 프런트엔드 프로그램의 패키지 구조도 정의해야 하는데, 이는 마이크로서비스 팀이 담당하는 업무를 고려하여 결정해야 함.
  • 마이크로 프런트엔드 패턴을 적용하여 백엔드와 마찬가지로 물리적으로 분리할 수도 있고, 모노리스 구조를 유지한다면 패키지별로 명확히 소유권이 구분되게 해야 함.

표준 레이아웃 정의

• 시스템의 목적과 기능에 따라 화면의 표준 레이아웃을 정의해야 함.
  • 이는 목록, 조회, 수정, 삭제 등의 주요 업무 화면 유형을 포함하며, 각 화면에 대한 사용자 경험을 고려함.
  • 또한, 화면을 구성하는 요소의 위치, 방식, 모양 등을 고려해야 함.

UI레이아웃 설계

• 표준 유형을 기반으로 각 개별 UI 레이아웃을 정의함.
  • 이는 각 기능을 만족시킬 UI를 정의하고, 화면에 표시될 속성 정보를 식별하며, 기능을 수행할 버튼 등을 정의하는 과정임.
  • UI 레이아웃을 정의할 때에는 업무 흐름에 따른 UI 흐름을 도출하며, 이를 보여주는 UI 스토리보드를 작성합니다.

UI 디자인 및 UI레이아웃 반영

표준 화면 유형에 맞는 UI 디자인을 정의하며, 이는 주로 웹디자이너가 수행함.

• 프런트엔드 엔지니어와의 긴밀한 협의가 필요하며, 디자인을 UI에 반영하는 과정에서 프런트엔드 엔지니어는 디자이너의 디자인 의도를 반영함.

이벤트 설계

• 화면의 이벤트 변화에 따라 백엔드 API를 호출하는 방식을 정의함.
  • 이는 사용자의 인터랙션에 따른 시스템의 반응을 결정하는 중요한 단계임.

5.5.2 백엔드 모델링

• 백엔드 마이크로서비스 설계는 헥사고날 아키텍처를 기반으로 함.
  • 헥사고날 아키텍처는 외부 영역과 내부 영역으로 분리되어 있음.
• 이벤트 스토밍의 결과는 헥사고날 아키텍처에 매핑될 수 있음.
  • 예를 들어, 이벤트 스토밍의 '커맨드'는 헥사고날의 인바운드 어댑터인 REST API가 됨.
  • '애그리거트'는 도메인 모델이 되고, '도메인 이벤트'는 아웃바운드 메시지 처리 어댑터의 처리 대상이 됨.
  • 마지막으로, '외부 시스템'은 아웃바운드 어댑터가 호출해야 할 외부 연계 시스템으로 매핑됨.
• 백엔드 모델링의 출발점은 이러한 요소들이지만, 실제 구현을 위해서는 더 구체적인 설계가 필요함.
  • 외부 영역 설계는 프런트엔드와 연계되는 'API 설계'로 진행되며, 내부 영역은 비즈니스 로직을 구현하는 '도메인 모델링'과 '데이터 모델링'으로 구체화됨.

API 설계

• 마이크로서비스 팀은 서비스의 프런트엔드와 백엔드 구현을 모두 책임지고, 이 두 영역 사이의 연계를 위해 API 설계가 필요함.
  • API는 백엔드 서비스에 존재하지만 프런트엔드의 요구사항을 충족하도록 설계되어야 함.
• API 영역은 헥사고날 아키텍처의 외부 영역에 속하며, 인바운드 어댑터의 역할을 함.
  • 이 영역은 어떤 호출 방식이든 허용되는 유연한 공간이지만, 최근에는 HTTP 프로토콜과 JSON 포맷을 사용하는 REST API가 표준처럼 사용되고 있음.
  • 이는 REST API가 HTTP 프로토콜, JSON 포맷, 간단한 HTTP 메서드 형식 등을 활용하여 쉽고 명확하게 사용할 수 있기 때문임.

REST API의 개념

• REST API는 HTTP 프로토콜을 기반으로 한 네트워크 아키텍처 스타일로, 자원(resource), 행위(verb), 그리고 표현(representations)이라는 구성요소로 이루어져 있음.
• 예를 들어, "홍길동이라는 사용자를 생성한다"는 API 요청에서 "사용자"는 자원, "생성한다"는 행위, 그리고 "홍길동"이 표현임.
  • 이를 REST API로 표현하면 “http://example.com/users/”라는 URI로 자원을 표현하고, HTTP의 POST 메서드로 행위를 표현하며, JSON 문서를 통해 "홍길동"이라는 사용자를 표현하게 됨.
• REST API는 자원을 URI 형식으로 표현하며, 보통 명사를 사용함.
  • 세부 항목은 ID를 붙여 표현하고, 이는 JSON 포맷을 통해 입출력 데이터로 사용됨.
  • 또한, 행위는 HTTP 메서드를 통해 표현됨.
• REST API의 이런 특성 덕분에, API의 구성요소만으로도 API의 내용을 직관적으로 이해하고 사용할 수 있어 매우 편리함.

REST API 성숙도

• 레오나르도 리처드슨이 정의한 REST API 성숙도 모델은 네 개의 레벨로 구성되어 있음.
  • 레벨 0은 원격 프로시저 호출(Remote Procedure Call) 방식으로 HTTP 프로토콜만 사용하며, REST API의 메커니즘을 전혀 사용하지 않는 단계임.
    • 하나의 URI 주소에 GET 방식의 URI 매개변수를 통해 입력, 수정, 삭제를 처리하는 방식임.
  • 레벨 1은 URI에 개별적인 자원을 표현하는 단계임.
    • 하나의 URI에 모든 요청을 보내는 대신, 요청이 필요한 대상을 특정하는 방식임.
    • 예를 들어, /products/apple처럼 특정 리소스에 대한 정보를 제공함.
  • 레벨 2는 약속된 HTTP 메서드를 사용하여 서비스의 기능을 처리하는 단계임.
    • GET, POST, PUT, DELETE 등의 메서드를 적절하게 사용하여, API 사용자가 어떤 메서드를 사용했을 때 어떤 행위가 발생할지 예측할 수 있음.
  • 레벨 3은 HATEOAS(Hypertext As The Engine Of Application State)라는 원칙을 적용하는 단계임.
    • 특정 요청의 반환값에 기대한 결과 외에도 추가적으로 사용자가 그 다음에 무엇을 할 수 있는지, 그것을 하기 위해 다룰 수 있는 URI 값을 함께 보내줌.
• 이 모델에서 REST API의 사용을 암묵적으로 가능하게 하는 레벨 2를 지향하는 것이 바람직하다고 함.
  • 이렇게 함으로써 API 사용자가 리소스에 어떤 메서드를 사용했을 때 어떤 행위가 발생할지 쉽게 이해하고 예측할 수 있게 됨.

API 설계 문서화

• API 설계 문서화는 프런트엔드와 백엔드 엔지니어들 사이의 협업을 촉진하며, 다른 설계 요소에 비해 공유가 중요함.
  • 문서화는 협업 시스템 내에서 간단한 위키 형태로 이루어질 수 있고, 필요하다면 엑셀 형태로 공식적인 문서를 작성할 수도 있음.
• API 설계 문서는 최소한 다음 정보를 포함해야 합니다:
  • 서비스명
  • API명
  • 리소스(URI)
  • 요청 매개변수
  • 요청 샘플
  • 응답 매개변수
  • 응답 샘플