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

요약

• 4장. 마이크로서비스와 애자일 개발 프로세스의 나머지 부분을 이해함.
  • 기민한 설계/개발 프로세스
    • 점진/반복적인 스크럼 생명주기
    • 아키텍처 정의와 마이크로서비스 도출
    • 스프린트 내 개발 공정
      • 백엔드 설계 및 개발
      • 프런트엔드 영역 설계와 개발
      • 빌드 및 배포
• 5장. 마이크로서비스 설계 앞부분에 대해 이해함.
  • 마이크로서비스를 도출하는 방법
    • 비즈니스 능력에 근거한 도출

메모

4.2 기민한 설계/개발 프로세스

• 마이크로서비스를 위한 기민한 설계/개발 프로세스는 DDD를 활용한 스크럼 기반의 마이크로서비스 개발 프로세스를 사용함.
  • 이 프로세스는 최소화된 핵심 설계 영역과 활동을 포함하며, 각 활동별로 최소한의 핵심 산출물을 정의함.
  • 이를 통해 단순하고 체계적이며, 효율적이면서도 기민한 반복적인 흐름을 반영한 개발 프로세스를 구현할 수 있음.

4.2.1 점진/반복적인 스크럼 생명주기

• 점진/반복적인 스크럼 생명주기는 스프린트를 활용하여 진행되며, 스프린트는 1~4주 동안 실행됨.
  • 스프린트는 백로그를 기반으로 진행되며, 매 스프린트마다 시연하고 피드백을 얻음.
  • 스크럼 팀은 다기능 팀으로 구성되어 있으며, 스크럼 마스터와 팀 멤버가 포함됨.
  • 스탠드업 미팅을 통해 일을 투명하게 공유함.
• 스프린트 계획 수립 시 제품 백로그에서 일감을 스프린트에 배분하고, 스프린트 종료 시 완료된 백로그를 기준으로 팀의 생산성(속도)를 결정함.
  • 이 속도는 프로젝트를 예측하고 다음 스프린트 계획을 세우는 데 중요함.
  • 이 과정은 지속적인 계획(continuous planning)이라고 하며, 적응적(adaptive) 계획을 사용함.
• 스프린트 마지막 활동은 시연과 회고로, 시연은 백로그 구현 여부를 확인하고 피드백을 받는 자리이며, 회고는 팀원들이 개선점을 찾아 다음 스프린트에 적용할 수 있는 과정임.
  • 스프린트 내 설계 및 개발에 대한 공정이 존재하며, 스프린트에 들어가기 전의 설계 및 개발 작업도 포함됨.

4.2.2 아키텍처 정의와 마이크로서비스 도출

• 아키텍처 정의는 마이크로서비스 외부/내부 아키텍처를 정의하는 과정임.
  • 기술 세부사항은 늦게 결정할 수 있어야 하며, 애플리케이션은 소프트하고 유연해야 함.
  • 초기에는 최소한의 개발 및 테스트 환경을 준비하며, 클라우드 PaaS 개발 환경이 빠른 환경 구축을 도움.
  • ex) 외부 아키텍처를 미리 결정하면 빠르게 개발 환경을 구축하고 곧바로 개발 과정으로 진입할 수 있음.
    • 이러한 아키텍처는 스프린트 과정을 통해 개선되고, 지속적으로 정제될 것이다.
• 마이크로서비스 도출은 스크럼 팀이 개발할 전체 마이크로서비스들을 파악하는 작업임.
  • DDD의 전략적 설계 기법을 활용해 마이크로서비스를 도출하고, 대략적인 매핑 관계를 정의한 후 개발 우선순위에 근거해 스크럼 팀에 배분해서 스프린트를 진행함.
  • 최종 결과물은 컨텍스트 맵이며, 이는 마이크로서비스 간의 의존관계를 보여줌.

4.2.3 스프린트 내 개발 공정

• 스프린트 내의 공정은 스크럼 팀 멤버인 백엔드 개발자와 프런트엔드 개발자의 역할에 따라 나뉘며, 두 영역은 'API 설계'라는 계약을 통해 연결됨.
  • 이후의 활동은 각각 내부적으로 진행됨.

백엔드 설계 및 개발

• 백엔드 설계의 시작은 API 설계로, 이는 백엔드 마이크로서비스가 프런트엔드에 제공할 서비스 명세임.
  • 초기에 API 설계를 진행하고 프런트엔드 영역과 협의 및 조정해야 함.
  • 그 다음 백엔드 영역의 설계는 정의된 마이크로서비스 내부 구조에 따라 '도메인 모델'과 '데이터 모델'을 설계함.
• 도메인 모델링은 도메인 모델을 작성하는 활동이며, 이는 OOAD와 DDD 방식의 차이를 보여줌.
  • OOAD에서는 UML 등을 활용해 설계 모델을 작성하고, 이를 소스코드로 변환하는 반면, DDD를 적용하면 별도의 정형화된 모델을 만들지 않고, 간략히 도메인 모델을 화이트보드나 포스트잇 등의 도구로 작성해서 공유하고, 곧바로 소스코드로 도메인 모델을 개발함.
• 이는 MDD (Model Driven Development)와 DDD의 모델링 차이를 보여줌.
  • MDD는 추상적인 모델을 완벽히 만들어 놓고 특정 기술 프로파일이나 프레임워크를 적용해 구체적인 코드를 생성하는 반면, DDD의 모델링은 코드 자체가 모델의 기본 표현 형식을 그대로 반영해서 코드로 표현됨.
  • 때때로 개발자는 역공학 도구를 이용해 UML 모델로 역공학해서 볼 수 있음.
  • 따라서 DDD의 모델은 코드와 함께 항상 살아 숨쉬게 됨.

프런트엔드 영역 설계와 개발

• 프런트엔드 영역 설계는 UI 레이아웃을 정의하고, 백엔드의 API를 호출해서 API가 보내준 데이터를 기반으로 UI에 어떻게 표현할 것인가를 정의하는 활동임.
  • 사용자 접근 채널에 따라 모바일 앱, 웹 등의 레이아웃 정의가 다양할 수 있으며, 프런트 아키텍처에 따라 설계 수준 및 방식도 다를 수 있음.
• 프런트엔드 영역 설계와 개발의 기본적인 활동은 다음과 같음.
  • UI 흐름 정의: 비즈니스 흐름에 따른 UI 흐름을 정의하며, 이를 UI 스토리보드라고도 함.
  • UI 레이아웃 정의: 사용자 인터페이스를 정의하는 활동으로, 사용자 경험을 고려해서 설계함.
    • 파워포인트, 발사믹 목업, 카카오 오븐 등 다양한 도구를 사용할 수 있음.
  • UI 이벤트 및 액션 정의: UI 레이아웃의 구성요소인 컨트롤을 클릭하거나 터치 등의 행위를 했을 때 발생하는 이벤트 및 액션을 정의함.
    • 백엔드 API와의 연계를 정의할 수도 있음.
  • UI 개발: UI 레이아웃 및 이벤트의 의도에 맞춰 프런트엔드 애플리케이션을 개발함.
    • 프런트엔드 아키텍처에서 정의한 UI 프레임워크나 도구를 사용할 수 있음.

빌드 및 배포

• 기민한 개발을 위해 빌드 및 배포 환경을 자동화해야 함.
  • 스크럼 팀의 구성원은 언제라도 현재 진행된 만큼의 실제로 돌아가는 소프트웨어를 확인할 수 있어야 함.
  • 데브옵스 인프라 환경이 이를 지원하며, 백엔드 및 프런트엔드 개발자는 매일 통합 빌드되고 배포되는 개발 환경에 익숙해져야 함.
• 아키텍처를 정의할 때 수행해야 할 빌드 및 배포를 위한 활동은 다음과 같음.
  • 소스코드 리포지토리 구성: 프런트엔드, 백엔드 코드를 위한 소스코드 리포지토리를 구성함 (ex: SVN, Git, GitHub).
  • 통합 빌드잡 구성: 소스코드를 통합한 후 컴파일 및 테스트해서 바이너리를 만드는 활동을 자동화함 (ex: 젠킨스).
  • 컨테이너 생성 파일 작성: 운영체제와 WAS와 빌드된 애플리케이션을 묶어서 컨테이너 이미지를 생성하는 스크립트를 작성함 (ex: Dockerfile).
  • 배포 스크립트 작성: 자동으로 배포하는 스크립트를 작성함.
    • 배포 타깃에 맞춰 스크립트를 작성하며, 젠킨스 등 도구로 온프레미스 및 클라우드 서비스 등 대부분의 환경에 자동화해서 배포할 수 있음.

05. 마이크로서비스 설계

• 소프트웨어 개발의 역사에서 모듈화의 중요성은 변하지 않음.
  • 모듈화의 근본적 가치는 각 모듈을 기능적으로 응집성 높게 만들고(high cohesion), 기능이 다른 타 모듈간의 의존도를 낮추는 것(low coupling)임.
• 마이크로서비스 설계에서의 가장 중요한 관심사도 어떻게 기능적으로 응집성 있는 마이크로서비스를 도출하고 타 서비스 간의 의존도는 낮출 것인가임.
  • 마이크로서비스의 내부 구조를 구성하는 각 요소들도 역할별로 모듈화돼야 함.
• 각 역할이 분명한 응집성 있는 서로 의존성이 낮은 모듈들이 모여 마이크로서비스를 이루고, 이 마이크로서비스는 다른 마이크로서비스와 의존성이 낮아야 함.
  • 마이크로서비스를 구성하는 각 요소들이 모두 소프트, 즉 유연해야 함.
• DDD의 전략적 설계와 전술적 설계가 이를 위한 적절한 가이드를 줌.
  • DDD를 중심으로 마이크로서비스를 도출하고 설계하는 방안들을 살펴볼 예정임.

5.1 마이크로서비스를 도출하는 방법

• 마이크로서비스가 비즈니스의 변화 속도를 지원하면서 독립적으로 변경 및 배포되려면 각 마이크로서비스가 다른 서비스와 의존하지 않게 도출해야 함.
  • 어떤 비즈니스 기능들을 독립적인 마이크로서비스로 도출할 것인가를 결정하는 것이 중요함.

5.1.1 비즈니스 능력에 근거한 도출

• 마이크로서비스를 식별하는 가장 쉬운 방법은 경험적인 원칙을 적용하는 것임.
  • 비즈니스 능력(capability)에 따라 서비스로 식별할 수 있음.
  • 비즈니스 능력은 비즈니스 가치를 생산하기 위해 하는 일이며, 조직이 하는 일임.
• 각 도메인에서는 비즈니스가 규정하는 일하는 방식과 조직, 부서 체계가 이미 정의돼 있고, 이러한 부서는 이미 업무 처리에서의 응집성을 가지고 있고 타 부서와의 의존도는 낮음.
  • 이처럼 비즈니스 부서가 가진 역할, 처리 능력을 체계적으로 분해할 수 있으며, 이를 업무 기능 분해라고 함.
  • 업무 기능 분해는 업무 흐름에 따라 업무를 최상위에서 하위까지 대, 중, 소의 크기로 분리하고 수행하는 일들을 체계적으로 정렬함.
• 이를 기반으로 직관적으로 서비스를 식별할 수 있음.
  • 대, 중, 소의 분류 중 어떤 레벨을 서비스로 식별해야 하는지 고민이 될 수 있지만 쉽게 도출할 수 있음.
  • 그러나 이러한 방식은 전체적인 대략의 비즈니스를 이해할 때는 유용하지만 서비스 간의 관계를 파악하거나 서비스의 구체 기능과 연관된 서비스가 관리할 독립적인 데이터를 식별하기에는 미흡함.
  • 이를 보완할 대책이 필요함.