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

요약

• 7장. 사례연구 - 백엔드 마이크로서비스 구현에 대한 내용
  • 도서 대출 마이크로서비스 개발
    • 구현 기능 소개
      • 도서 대출
      • 도서 반납
      • 도서 연체
      • 연체 해제
    • 내부 아키텍처 결정
    • API 설계
    • 도메인 모델링
    • 유스케이스 흐름

메모

7장. 사례 연구 - 백엔드 마이크로서비스 구현

• 이번 장은 세부 구현 코드보다는 도메인 모델링을 수행하고 마이크로서비스의 내부 구조를 정의하는 데 초점을 두고 진행함.
• 앞에서 구성한 내부 아키텍처를 기반으로 다음과 같은 순서로 진행함.
  1. 구현 기능 소개
  2. 내부 아키텍처 결정사항
  3. API 설계
  4. 도메인 모델링
  5. 유스케이스 흐름
  6. 내부 영역 개발
  7. 외부 영역 개발
  8. 단위 테스트 수행

7.1 도서 대출 마이크로서비스 개발

7.1.1 구현 기능 소개

• 이 마이크로서비스는 도서 대출, 도서 반납, 도서 연체, 도서 연체 해제와 같은 핵심 기능을 담고 있음.
  • 이들 기능은 내부 비즈니스 로직뿐만 아니라 외부 서비스와의 연계를 통해 구현되었음.
  1. 도서 대출
     • 대출 처리에 대한 비즈니스 로직을 구현하며, 도서 서비스와 연계하여 상세 도서 정보를 조회하고(페인 동기 호출) 재고 감소를 처리함(카프카 비동기 전송).
     • 또한, 카탈로그 서비스에 대출 도서 집계 처리를 함(카프카 비동기 전송).
  2. 도서 반납
     • 반납 처리에 대한 비즈니스 로직을 구현하며, 도서 서비스와 연계하여 재고 증가를 처리함.
  3. 도서 연체
     • 연체 처리에 대한 비즈니스 로직을 구현하며, 연체 시 대출이 불가능하게 처리함.
  4. 도서 연체 해제
     • 연체 해제를 위해 사용자 서비스와 연계하여 포인트를 통해 결제 처리를 함.

7.1.2 내부 아키텍처 결정

• 도서 대출 서비스에서는 도메인 모델 중심의 헥사고날 아키텍처를 적용함.
  • 저장소 메커니즘으로는 OR 매퍼인 스프링 데이터를, 동기 통신을 위한 메커니즘으로는 페인을, 비동기 통신을 위한 메커니즘으로는 카프카를 사용함.

7.1.3 API 설계

• 다음의 네 가지 주요 API를 구현함
  1. 도서 대출 API
     • 사용자와 대출하려는 도서의 일련번호를 받아 대출 처리를 함.
     • 대출 가능한 경우 도서 대출 정보를 반환함.
  2. 도서 반납 API
     • 사용자와 반납하려는 도서의 일련번호를 받아 반납 처리를 함.
     • 요청 완료 시 도서 대출 정보를 반환함.
  3. 도서 연체 처리 API
     • 대출 완료된 도서를 연체 아이템으로 변경함.
     • 연체 처리된 도서의 일련번호를 반환함.
     • 한 권이라도 연체되면 사용자의 도서 대출 상태는 도서 대출 불가 상태가 됨.
  4. 연체 아이템 반납 처리 API
     • 연체된 도서를 반납함.
     • 반납 후에도 연체료가 남아있으면 사용자의 대출 가능 상태는 '도서 대출 불가'로 유지됨.

7.1.4 도메인 모델링

• 도메인 모델링의 주요 목표는 비즈니스 개념을 객체 모델로 만들어서 모든 이해관계자가 쉽게 이해할 수 있도록 하는 것임.
  • 이 작업을 수행하는 방법 중 하나는 비즈니스를 "로봇"으로 생각하는 것.
• 여기서는 도서대출로봇이라는 개념을 도입하여 도서 대출, 연체, 반납 등의 과정을 설명함.
  • 이 로봇은 도서 대출 정보를 기록하며, 대출 가능 여부를 결정하는 로직을 갖고 있음.
  • 예를 들어, 도서가 연체되면 이 로봇은 해당 사용자의 대출 가능 여부를 '불가'로 변경함.
• 이 도메인 모델은 Rental 엔티티로 표현되며, 대출아이템(RentedItem), 연체아이템(OverdueItem), 반납아이템(ReturnedItem) 등의 개념이 포함됨.
  • 각 아이템은 Rental과 일대다 관계를 갖는다.
• Rental 엔티티는 도서 대출의 전체적인 책임을 가지고 있으며, 대출 아이템이 생성되고, 연체 아이템으로 이동하거나, 반납 아이템으로 최종 이동하는 등의 프로세스를 관리함.
  • 또한, 대출 가능 여부는 RentalStatus라는 표준 타입에 의해 결정됨.

7.1.5 유스케이스 흐름

• 도서 대출 및 반납의 비즈니스 로직은 도메인 모델에 응집되어 있고, 서비스 구현체는 비즈니스 로직 외의 흐름 제어 및 저장 처리를 담당함.
  • 유스케이스 흐름을 시퀀스 다이어그램으로 작성할 수 있음. p235 참고

API가 먼저인가, 도메인이 먼저인가?

• 이는 프런트엔드(UI) 설계와 백엔드(도메인) 모델링의 순서에 영향을 줌.
• 결론적으로, 양쪽이 각자의 주 설계 영역인 UI 설계와 도메인 모델링을 각각 선행하고, 어느 정도 양쪽이 정리된 후에 API를 확정하는 것이 좋음.
  • 그 이유는 도메인 모델링이 선행되지 않으면 프런트엔드 중심의 API가 나오고, API의 재사용성이 떨어지며 중복 개발의 경향이 높아질 수 있기 때문임.
• 따라서 도메인 모델링이 어느 정도 완료된 후에 API 설계를 진행하며, API 설계 협의에 따라 양쪽 설계 영역이 계속 정제되고 발전되어야 함.
  • 이를 통해 API는 프런트엔드 UI에 대한 의존도를 최소화하고, 서비스에서 제공할 API를 효과적으로 정리하고 구체화할 수 있음.
• 마지막으로, 개발 과정은 '내부 영역의 도메인 → 서비스 → 외부 영역의 REST 컨트롤러 → 아웃바운드 어댑터 인바운드 어댑터' 순으로 진행되어야 함.