IT STUDY LOG
Sprint - 도메인 주도 설계 실습 본문
#해결 과제
💡 도메인 주도 설계 예시
💡 도메인 주도 설계 실습
#실습 자료
#과제 항목별 진행 상황
✏️ 도메인 주도 설계 예시
이벤트 스토밍
- 이벤트 스토밍의 목적은 팀 전체가 도메인 지식을 공유를 통해 프로젝트의 방향성을 얼라인(align)시키는 것
- 이 과정에는 프론트엔드 개발자, 백엔드 개발자, 데브옵스 개발자, 인프라 엔지니어 등의 소프트웨어 관련 담당자만 참여하는 것이 아닌 하나의 프로젝트 팀에 속하는 기획자와 프로젝트 매니저, UI/UX 디자이너 등 모든 인원이 참가
- 모든 구성원이 이해할 수 있는 형태와 언어로 프로젝트를 시각화
- 완성된 결과물을 가지고 모든 팀 구성원이 하나의 방향성을 가진 상태로 각자의 역할을 수행
- 일반적으로는 모두가 모여있는 공간에서 큰 화이트보드나 벽에 포스트잇을 자유롭게 붙이는 방식으로 실행되는데, 온라인 환경에서는 miro와 같은 툴을 이용해서 비슷한 효과를 기대 가능
도메인 주도설계의 주요 용어
- 도메인 이벤트: 발생한 사건
- 커맨드: 도메인 이벤트를 트리거하는 명령
- 외부 시스템: 도메인 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템
- 액터: 개인 또는 조직의 역할
- 핫스팟: 의문사항, 결정하기 힘든 사항
- 애그리거트: 도메인 이벤트와 커맨드가 처리하는 데이터, 상태가 변경되는 데이터
- 정책: 이벤트 조건에 따라 진행되는 결정, “이벤트”가 발생할 때, “커맨드”를 실행한다
- 정보: 액터에게 제공되는 데이터, 결정을 내리는데 영향을 주는 정보
이벤트스토밍 과정
Step 1 : miro를 통해 팀원들이 모였다면 주요 용어 포스트잇을 배치
Step 2 : 도메인 이벤트를 찾기
- 도메인이벤트는 시간흐름에 따른 시스템의 동작을 의미
- 상태의 생성 / 변경 / 삭제가 발생하게 만듦
- 비즈니스 흐름에서 발생한 이벤트에 초첨을 맞춰서 결정
- 과거 시제 또는 명사형으로 기록 ex) 회원가입되었다 or 회원가입됨
- 자유로운 의견을 통해 도출된 도메인 이벤트들을 발생 순서를 고려하여 배치
Step 3 : 외부 시스템을 필요로 하는 프로세스를 찾아서 도메인 이벤트 뒤에 붙이기
- 명사형으로 작성
- 아이템이 주문되었을 때 결제하는 과정은 외부 결제시스템을 이용
- 결제가 승인되었을 경우 외부 이메일시스템을 통해 결과를 전송
Step 4 : 커맨드를 도메인 이벤트 앞에 배치
- 하나의 커맨드에 여러 개의 이벤트가 발생 가능
- 개발자 입장에서 구현하게 되는 API가 됨
Step 5 : 핫스팟을 찾아서 배치
- 궁금한 사항이나, 좀 더 논의가 필요한 사항, 결정하기 힘든 사항에 대한 내용을 붙임
Step 6 : 액터를 찾아서 배치
- 액터는 사용자의 역할을 뜻함
- 비즈니스를 수행하는 구체적인 역할을 고려해서 도출
- 해당 쇼핑몰 사례에서는 사용자를 게스트, 회원, 판매자, 구매자 등으로 구분 가능
Step 7 : 문장으로 액터, 커맨드, 이벤트를 검토
- "{구매자:액터}가 상품 {주문을 취소:커맨드}하면 {상품주문취소됨:도메인이벤트} 이벤트가 발생하고, 이어서 주문 취소된 상품의 재고를 변경하는 {상품재고수정:커맨드}이 실행되어서 {상품재고수정됨:도메인이벤트} 이벤트가 발생함으로써 시스템이 동작한다"
Step 8 : 애그리거트를 정의
- 애그리거트는 가장 작은 도메인 모델의 모듈 단위
- 커맨드와 도메인 이벤트가 영향을 주는 데이터 요소
- 개발자의 입장에서 보면, 도메인의 실체 개념을 표현하는 객체(엔티티)로 구현하게 될 대상
- 커맨드와 도메인 이벤트 사이 상단에 겹쳐서 붙임
Step 9 : 바운디드 컨텍스트를 정의하고 정책을 도출
- 도메인이벤트와 커맨드, 액터, 애그리거트를 고려해서 경계를 식별
- 애그리거트의 이름으로 컨택스트 이름을 정의하며이 과정에서 동일 애그리거트 중심으로 모듈화가 이루어짐
- 정책(이벤트 뒤에 따라오는 반응적인 비즈니스 로직)을 도출해서 붙임
- 어딘가의 커맨드를 작동시키는 역할을 하기 때문에 도메인 이벤트와 커맨드 사이에 존재
Step 10 : 호출 관계의 방향성을 고려하여 컨택스트 매핑을 진행
- 바운디드 컨텍스트 간의 관계를 파악
- 동기적 호출방식과 비동기적 호출방식을 고려한 표현도 가능
> 동기적(실선) : 항상 일관된 데이터 필요, 콘텍스트 간 의존도가 높음
> 비동기적(점선) : 결과적 일관성으로 처리가능한 관계
(ex) 클라이언트 -> 구매 컨텍스트 (동기적) -> 고객이 상품을 주문 : 즉시 수행되어야 함 / 클라이언트 -> 상품 컨텍스트 (동기적) -> 고객이 상품정보를 조회 : 즉시 수행되어야 함
구매컨텍스트 -> 배송 컨텍스트 (비동기) -> 배송 컨텍스트에 장애가 발생해도 주문을 받아둠, 배송 시스템 정상화 시 주문-배송 연결 -> 고가용성을 보장
✏️ 도메인 주도 설계 실습
- 환자 관리 정보시스템을 설계
- 도메인 주도 설계 원칙을 기반으로 설계
업무 개요
- 중앙방역대책본부에는 다양한 팀(DDD의 관점에서는 Actor)이 있지만, 대중에게 가장 잘 알려진 다음의 네 팀의 업무만을 이해
환자관리팀
- 재택치료제도를 통해 환자를 치료해야 함
- 환자가 n일 이후에 격리해제 기준에 부합하는지 확인해야 함
- 무증상이고, 호전되는 경우 격리 해제가 가능
- 유증상이고, 증상이 호전되지 않을 경우 PCR 검사를 다시 진행
역학조사팀
- 전자출입명부 및 카드 승인 내역을 기반으로 확진자의 동선을 조사하고, 밀접 접촉자를 확인
격리관리팀
- 확진자에게 격리 및 격리 해제를 통지하고, 자가격리자가 격리 중에 있는지, 또는 격리 위반을 했는지 확인
진단검사운영팀
- 선별진료소를 운영하고 PCR 검사를 통해 확진 여부를 파악
도메인 주도 설계의 주요 용어
- 도메인 이벤트: 발생한 사건
- 커맨드: 도메인 이벤트를 트리거하는 명령
- 외부 시스템: 도메인 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템
- 액터: 개인 또는 조직의 역할
- 핫스팟: 의문사항, 결정하기 힘든 사항
- 애그리거트: 도메인 이벤트와 커맨드가 처리하는 데이터, 상태가 변경되는 데이터
- 정책: 이벤트 조건에 따라 진행되는 결정, “이벤트”가 발생할 때, “커맨드”를 실행
- 정보: 액터에게 제공되는 데이터, 결정을 내리는데 영향을 주는 정보
Bare Minimum Requirement
1. 도메인 모델을 생성
- 애그리거트, 커맨드, 도메인 이벤트, 정책을 먼저 줄글로 나열하고, 그 관계를 다음 그림과 같이 그리기
2. 애그리거트 루트(보통은 액터로 나눌 수 있음)와 그에 관련된 바운디드 컨텍스트를 설정하고, 연관 관계를 정의
워크숍 순서
- 도메인 이벤트 찾기
- 외부 시스템/외부 프로세스 찾기
- 커맨드 찾기
- 액터 찾기
- 애그리거트 정의
- 바운디드 컨텍스트 정의
- 컨텍스트 매핑
액터 별 도메인 모델 생성 예
관리 (환자관리팀)
- 확진자 (Patient)
- aggregate
- 증상 여부
- 유증상 symptomatic
- 무증상 asymptomatic
- 증상 여부
- command
- 코로나 진단
- 재택 치료
- 격리기준 확인
- 증상 확인
- domain event
- 증상 발생
- PCR 검사 진행됨
- 코로나 확진됨
- 재택 치료됨
- n일 이후 무증상
- → 격리 해제
- n일 이후 유증상자 (호전되지 않는 경우)
- → PCR 검사가 진행됨
- 격리해제됨
- system
- PCR 시스템
- SMS 시스템
- actor
- 증상의심자
- 확진자
- aggregate
격리 (격리관리팀)
- 격리
- aggregate
- 격리 여부
- 격리 됨
- 격리해제 됨
- 격리 여부
- command
- 격리 관리
- domain event
- 격리 통지
- 격리중 확인
- 격리 해제 통지
- 격리 위반 확인
- system
- SMS 시스템
- actor
- 격리 관리팀 부서
- aggregate
- 격리 물품
- aggregate
- 격리 물품 유무 여부
- 격리 물품 있음
- 격리 물품 없음
- 격리 물품 배송 여부
- 격리 물품 배송 됨
- 격리 물품 배송 안됨
- 격리 물품 유무 여부
- command
- 격리 물품 관리
- domain event
- 격리중 필수품 확인
- 격리중 필수품 주문
- 주문 완료 됨
- 격리중 필수품 전달
- system
- 결제 시스템
- 배송 시스템
- actor
- 격리 관리팀 부서
- aggregate
조사 (역학조사팀)
- 감염 검증
- aggregate
- 감염자 네트워크
- command
- 접촉 확인 여부
- domain event
- 밀접 접촉자 확인
- system
- SMS 시스템
- actor
- 조사원
- aggregate
- 동선 검증
- aggregate
- 확진자 동선
- command
- 확진자 동선 관리
- domain event
- 확진자 방문 여부
- 환자 동선 조사
- actor
- 조사원
- aggregate
- 동선 검증
- aggregate
- 확진자 동선
- command
- 전자출입명부 조회
- domain event
- 전자출입명부 확인
- system
- 전자출입명부 확인 시스템
- actor
- 조사원
- aggregate
- 전자 출입 조회
- command
- 전자출입명부 조회
- domain event
- 전자출입명부 확인
- system
- 전자출입명부 확인 시스템
- actor
- 조사원
- command
- 카드내역조회
- command
- 카드 승인 내역 조회
- domain event
- 카드 승인 내역이 확인
- system
- 카드 내역 조회 시스템
- actor
- 조사원
- command
검사 (진단검사운영팀)
- 진료소
- aggregate
- 진료소
- command
- 선별 진료소 운영
- domain event
- 진료소 시설 관리
- 진료소 인력 관리
- actor
- 진료소 운영팀
- aggregate
- 지원
- aggregate
- 지원
- command
- 생활 지원금 지급
- domain event
- 코로나 생활 지원금 지급
- system
- 생활지원금 지급 시스템
- actor
- 지급담당자
- aggregate
- 검사
- aggregate
- 설문
- 검사
- command
- 설문조사
- PCR 검사
- 확진자 등록
- domain event
- 설문 조사
- PCR 검사로 확진 여부 파악
- 의심 확진자 신원 의심 됨
- system
- 설문조사 시스템
- 확진자 등록 시스템
- actor
- 설문 담당자
- 검사원
- aggregate
'devops bootcamp 4 > pair/team log' 카테고리의 다른 글
Sprint - 서버리스 애플리케이션 (0) | 2023.05.11 |
---|---|
Sprint - API Gateway와 서버리스 애플리케이션 (1) | 2023.05.11 |
Sprint - 환경 변수 설정 (0) | 2023.04.24 |
Sprint - 서버 배포 파이프라인 (0) | 2023.04.24 |
Sprint - 클라이언트 배포 파이프라인 (0) | 2023.04.24 |