개요
- 마이크로서비스 내부 아키텍처를 알아본다
- 마이크로서비스 개발 프로세스를 알아본다
마이크로서비스 내부 아키텍처
- Backend의 기본적인 Layered 아키텍처
- 과거 데이터 액세스 레이어에서 쿼리에 복잡한 비즈니스 로직을 넣어서 처리했기 때문에 값 비싼 DB(ex: 오라클)를 계속해서 쓸 수 밖에 없는 상황이 발생
- 레이어드 아키텍처 개선
- 레이어드 아키텍처에서 비즈니스 로직 레이어에 비즈니스 로직이 들어갔을 때 수정 사항이 발생한 경우 의존성때문에 해당 비즈니스 로직을 여러 군데서 호출하는 경우 항상 영향도를 파악해야 한다
- 따라서 도메인 레이어가 추가되면서 비즈니스 레이어와 분리된 형태가 생김
- DIP (Dependency Inversion Principle)
- 의존관계 역전 원칙 - 의존하려면 잘 변경되지 않는 부분에 의존해야 함
- 안정된 방향으로 의존하여 다른 패키지가 변경받을 때 영향을 덜 받도록 하는 것
- 다른 레이어에 가장 큰 영향을 줄 것 같은 위치에 있는 레이어의 의존방향을 바꿔 적용함(인터페이스 구현)
- DIP를 적용함으로써 기존 레이어드 아키텍처의 프레젠테이션 레이어→ 비즈니스 로직 레이어 → 데이터 액세스 레이어 처럼 상호 의존적이던 구조가 위 그림처럼 중간층의 레이어가 상하 레이어의 의존을 받도록 설계하여 의존 관계 역전 적용
헥사고날 아키텍처
- 위의 레이어드 아키텍처 개선버전에서 좀 더 진화한 버전
- 클린아키텍처
- 폴리그랏 아키텍처
- 요구 사항에 맞는 언어, DB, 프레임워크 유연하게 사용 - 엔티티 정의 시, 헥사고날이나 클린아키텍처에서는 데이터베이스가 중심이 아니라 객체 모델에 비즈니스 로직을 담으려고 한다 → DDD
- 헥사고날 아키텍처 적용
- 외부 영역(Adapter)과 내부 영역(Port)의 구분
- 핵심 : 외부 요인은 변경되기 쉽기 때문에 의존관계는 Entity (도메인) 중심이라는 것
애자일 적용 마이크로서비스 개발 프로세스
- 아키텍처 정의
- 레이어드? MSA? 헥사고날? 클린? → 프로젝트 성격에 맞는 아키텍처를 선택
- 스프린트 백로그 기준 마이크로서비스 도출
- 전략적 설계
- Bounded Context, 마이크로서비스를 도출 하는 것. 상호간에 유사하다.
- 서비스 간 연계는 Context Mapping
- 도메인 주도 설계의 전략적 설계는 이벤트 스토밍 기법을 가장 많이 사용
- 전략적 설계
- 백엔드 설계
- 백엔드 구현
