라온스토리 사내 발표 자료 2021/07/02 1차 발표

1. 주명돈
Domain Driven Design
도메인 주도 설계

2. 목차
• 설계의 영역?
• 배경 지식
• DDD란?
• HOW?

3. 설계의 영역

4. 설계의 영역
기존 방식
Architect - 소프트웨어 설계자

5. 설계의 영역
최근 방식
무거운 설계 영역 -> 스프린트 단위 빠르게 대응

6. 설계의 영역
개발자의 역할
개발 뿐만 아니라 설계를 같이하는 것이 “일반화”

7. 설계의 영역
문제점
Before : 설계 -> 개발 = 시간 증가
After : 개발 + 설계 = 고민없는 설계

8. 설계의 영역
고민 없는 설계 - 배경
생산성 증가 처럼 보임
“Side E
ff
ect”

9. 배경 지식 알아두면 좋은 개념

10. 배경지식
• 결합도와 응집도 Coupling & Cohesion
• 유연성 Flexibility
• 재사용성 Reusability
• 단단함 Robustness
• 회복력 Resilience

11. 결합도

12. 응집도

13. 배경지식
• 유연성 Flexibility - 요구사항 변화에 쉽게 적응하는가
• 재사용성 Reusability - 특정 기능, 컴포넌트가 재사용할 수 있는가
• 단단함 Robustness - 시스템이 얼마나 잘 버티는가
• 회복력 Resilience - 문제 발생 시 잘 회복할 수 있는가

14. 도메인 주도 설계 Domain Driven Design

15. 도메인은 소프트웨어가 아닌 실제 비지니스 영역을 의미한다.
“도메인?”

16. 항공기 운항의 대한 전문적 지식
항공기 운항 관리 소프트웨어

17. 도메인 주도 설계
소프트웨어 자체로부터 시작하는 설계가 아닌
도메인 영역으로부터 시작하는 설계를 의미함

18. 도메인 주도 설계
소프트웨어의 궁극적인 목표
소프트웨어 자체의 문제가 아닌
실제 생활에 존재하는 “어떤 문제”를 해결하는 것

19. 문제 자체를 이해하지 못한상태에서 설계와 개발이 진행된다면
100% 산으로 간다

20. Deep Dive

21. 제한된 컨텍스트
Bounded Context
광고
사용자관점
“특정 제품 혹은 서비스로
이동하는 이미지”
=
이미지 정보, 이동 URL

22. 제한된 컨텍스트
Bounded Context
광고
광고 관리자 관점
“나의 돈버는 수단”
=
광고 기간, 광고 대상 사용자
, 광고 비용 등

23. 제한된 컨텍스트
Bounded Context
광고
광고주 관점
“홍보”
=
광고 효과, 효율

24. 제한된 컨텍스트
Bounded Context
이미지 정보, 이동 URL
광고 기간,
광고 대상 사용자
, 광고 비용, 광고 효과,
효율 등
“광고”

25. 제한된 컨텍스트
Bounded Context
광고주 관점
“홍보”
=
광고 효과, 효율
광고 관리자 관점
“나의 돈버는 수단”
=
광고 기간, 광고 대상 사용자
, 광고 비용 등
사용자관점
“특정 제품 혹은 서비스로
이동하는 이미지”
=
이미지 정보, 이동 URL
“광고”

26. 제한된 컨텍스트
Event Storming

27. 제한된 컨텍스트
전략적 설계
“규모가 큰 프로젝트에서는 다수의 모델이 사용되기 마련이다.
그러나 개별적인 모델을 기반으로 작성된 코드가 한데 섞이면
많은 버그가 발생하고 신뢰성이 떨어지며 이해하기 힘든 소프트웨어가 만들어진다.
아울러 팀 구성원 간의 의사소통이 혼란스러워진다.
종종 어떤 컨텍스트에서 어떤 모델을 사용해서는 안 되는지 불분명한 경우도 있다”
에릭 에반스

28. How ?

29. HOW ? 구현하기
개요
다음으로 도메인의 경계가 있는
컨텍스트 를 정의합니다.
각각의 제한된 컨텍스트에는
큰 애플리케이션의 특정 하위 도메인을
나타내는 도메인 모델이 포함됩니다.
애플리케이션의 기능 요구 사항을
이해하기 위한 비즈니스 도메인
분석부터 시작합니다.
이 단계의 결과는 비공식적인 도메인
설명으로, 보다 공식적인 도메인
모델 세트로 구체화할 수 있습니다.
제한된 컨텍스트 내에서
전술적 DDD 패턴을 적용하여
엔터티, 집계 및 도메인 서비스를
정의합니다.

30. HOW ? 구현하기
시나리오 : Drone 배달
Laonstory 라는 회사가 드론 배달 서비스를 시작합니다. 이 회사는 다수의 드론 항공기를 관리합니다.
기업은 서비스에 등록하고 사용자는 배달을 위해 드론이 상품을 픽업하도록 요청할 수 있습니다.
사용자가 픽업을 예약하면 백 엔드 시스템이 드론을 할당하고 사용자에게 예상 배달 시간을 알립니다.
배달이 진행되는 동안 지속적으로 업데이트되는 ETA를 통해 고객은 드론의 위치를 추적할 수 있습니다.
이 시나리오에는 상당히 복잡한 도메인이 포함됩니다. 비즈니스 우려 사항으로는 드론 예약, 패키지 추적,
사용자 계정 관리, 기록 데이터 저장 및 분석 등이 있습니다.
또한 Laonstory는 빠르게 시장에 진입 및 반복하며 새로운 기능을 추가하고자 합니다.
애플리케이션은 SLO(서비스 수준 목표)가 높은 클라우드 규모에서 작동해야 합니다. 또한 시스템의
각 부분에서 데이터 스토리지 및 쿼리에 대한 요구 사항이 완전히 달라야 합니다.
이러한 모든 사항을 고려한 끝에 Laonstory 는 드론 배달 애플리케이션에
마이크로 서비스 아키텍처를 사용하기로 선택합니다.

31. HOW ? 구현하기
Event Storming : Drone 배달

32. HOW ? 구현하기
도메인 분석 : Drone 배달
• 배송 은 이 비즈니스의 핵심이므로 다이어그램의 중앙에 있습니다. 다
이어그램의 다른 모든 항목은 이 기능을 구현하기 위해 존재합니다.
• 드론 관리 도 이 비즈니스에서 핵심입니다. 드론 관리와 밀접한 관련
이 있는 기능에는 드론 복구 와, 드론 서비스 및 유지 관리가 필요한
시점을 예측하는 예측 분석 이 포함됩니다.
• ETA 분석 은 수거 및 배달에 대한 추정 시간을 제공합니다.
• 타사 운송 은 드론만으로는 패키지를 배송할 수 없는 경우 대체 운송
수단을 예약하는 애플리케이션을 구현합니다.
• 드론 공유 는 핵심 비즈니스의 가능한 확장입니다. 회사에서 특정 시
간대에 용량이 남아 유휴 상태가 되는 드론을 대여할 수 있습니다. 이
기능은 초기 릴리스에 없습니다.
• 비디오 감시 는 회사가 나중에 확장할 수 있는 다른 영역입니다.
• 사용자 계정, 청구 및 콜 센터 는 핵심 비즈니스를 지원하는 하위 도메
인입니다.

33. HOW ? 구현하기
Bounded Context: Drone 배달

34. HOW ? 구현하기 - 전술적 패턴
Shipping 시나리오: Drone 배달 패턴 적용
• 고객이 드론 배달 서비스에 등록한 기업으로부터 물품 수거를 위해 드론을 요청할 수 있습니다.
• 보내는 사람은 패키지에 표시할 태그(바코드 또는 RFID)를 생성합니다.
• 드론이 원본 위치에서 패키지를 수거하여 대상 위치로 배달합니다.
• 고객이 배달을 예약할 때 시스템은 경로 정보, 기상 상황, 이력 데이터를 기준으로 ETA를 제공합니다.
• 드론이 이동 중일 때 사용자는 현재 위치와 최신 ETA를 추적합니다.
• 드론이 패키지를 수거하기 전에는 고객이 배달을 취소할 수 있습니다.
• 배달이 완료되면 고객에게 알림이 전달됩니다.
• 보내는 사람은 서명이나 지문의 형태로 고객의 배달 확인을 요청할 수 있습니다.
• 사용자는 완료된 배달의 기록을 조회할 수 있습니다.

35. HOW ? 구현하기 - 전술적 패턴
Shipping 시나리오: Drone 배달 패턴 적용
•배달
•패키지
•드론
•계정
•확인
•알림
•태그
처음 4개, 즉 Delivery, Package, Drone 및 Account은 모두 트랜잭션 일관성 경계를 나타내는 집계 입니다.
Con
fi
rmations 및 Noti
fi
cations는 Deliveries의 자식 엔터티, Tags는 Packages의 자식 엔터티입니다.

36. HOW ? 구현하기 - 전술적 패턴
Shipping 시나리오: Drone 배달 패턴 적용

37. HOW ? 구현하기

38. End.
https://happycloud-lee.tistory.com/94