Programming/MSA

MSA에 대한 기본개념 - 3. Domain Driven Design 으로 가는 여정

armyost 2022. 6. 10. 07:35
728x90

어플리케이션 도메인의 변화

회사가 성장함에 따라 어플리케이션의 Core(중요한것)와 Supporting(덜 중요한것)으로 나누게 된다. 

 

예시)

Core

- 사용자들은 주문하기 위해 많은 상품을 클릭하고 "구매" 버튼을 클릭

- 상품이 주문되면 배송팀은 상품의 배송을 준비

- 주문이 취소되거나 완료되면 상품재고 수치 감소

 

Supporting

- 고객들은 매진된 상품을 구매할 수 있으며 이는 입고뒤 해소

- 배송 상태 변화시마다 Notification이 고객에게 전달

- 주문과 취소를 반복하는 고객은 블랙리스트로 관리

- 마케팅 팀은 매일 오전 9시에 추천상품을 메일링

 

 

회사가 더 규모가 성장하면 팀은 자치성과 동기부여를 위해 더 나뉘어 지게 된다. 

 

예시)

배송관리팀

- 상품이 주문되면 배송팀은 상품의 배송을 준비

- 배송 상태 변화시마다 Notification이 고객에게 전달

 

상품관리팀

- 주문이 취소되거나 완료되면 상품재고 수치 감소

 

주문/결제관리팀

- 고객들은 매진된 상품을 구매할 수 있으며 이는 입고뒤 해소

 

고객센터팀

- 배송 상태 변화시마다 Notification이 고객에게 전달

- 주문과 취소를 반복하는 고객은 블랙리스트로 관리

 

마케팅팀

- 마케팅 팀은 매일 오전 9시에 추천상품을 메일링

 


Micro Service를 나누면서 고민할 점

  • 어떻게 Micro Service를 쪼개면 좋은가?
  • 서비스를 어떻게 결함할 것인가?
  • 어떤 비즈니스 이벤트에 의하여 마이크로 서비스들이 상호 반응하는가?

 

마이크로서비스 간의 서열과 역학관계

1. Core Domain : 버릴 수 없는 이 기능이 제공되지 않으면 회사가 망하는

2. Supporting Domain

  • 기업의 핵심 경쟁력이 아닌, 직접 운영해도 좋지만 상황에 따라 아웃소싱 가능한
  • 시스템 리소스가 모자라면 외부 서비스를 빌려쓰는 것을 고려할만한

3. General Domain : SaaS 등을 사용하는게 더 저렴한, 기업 경쟁려고가는 완전 무관한

 

이러한 서열이 정해지면 높은 서열의 마이크로서비스의

  • 인터페이스를 더 중요하게 관리해야한다.
  • 서비스 화장의 우선순위를 높게 준다.

 

Micro Service를 나누는 수준

모놀리식을 쪼깨는 순서는 우선 처음에는 크게 Core와 Supporting을 쪼갠다. 다음 Business Capability 비즈니스적 목표에 따라 분리한다. Aggregate수준으로 너무 잘게 쪼개면 개발 비용이 매우 높아지고, 상호간 네트워크 부하가 생긴다. 

  • Core/Supporting : 간섭이 가장 높은 부분을 경계로 한. 시급한
  • Bussiness Capability : 비즈니스적 목표에 따라 분리
  • BC Original : 커뮤니케이션이 원활해지는
  • Aggregate : 더이상 쪼갤수 없는

 

Micro Service를 나누는 관점

  • 도메인 관정 : 업무 중요도와 자치성
  • 기술 관점 : 기술 아키텍처가 상이한 모듈
  • 트랜젝션 관점 : 트랜젝션 모형이 다른
  • 페르소나 관점 : 사용자 관점
  • 재사용 관점 : 변경시 동반되어 수정되어야 하는 영역 또는 유틸리티 성격의 서비스

DDD를 쉽게 하는 방법 Event Storming

  • 이벤트 스토밍은 시스템에서 발생하는 이벤트를 중심으로 분석하는 기법으로 특히 Non-Blocking, Event-Driven 한 MSA 기반 시스템을 분석에서 개발까지 필요한 도메인에 대한 탁월하게 빠른 이해를 도모하는데 유리하다. 
  • 기존의 유즈케이스나 클래스 다이어그래밍 방식과 다르게 별다른 사전 훈련된 지시고가 도구없이 진행할 수 있다. 이를통해 현업에서는 IT적 배경이 없더라도 이해할 수 있음
  • 진행과정은 참여자 워크숍 방식의 방법론으로 결과는 스티커 노트를 벽에 붙힌것으로 결과가 남으며 오랜지색 스티커 노트들의 연결로 비즈니스 프로세스가 도출되며 이들을 이후 BPMN과 UML등으로 정제하여 전환할 수 있다. 

여기서 도출된 Bounded Context 단위로 Micro Service가 되고 즉 단일 컨테이너가 된다. 

 

DDD 전반전은 고객이 주도적으로 프로세스레벨의 그림을 그리고
후반전은  엔티티 타입. 매핑, 객체에 Sync를 수행하여 상세화 한다.