도메인 주도 설계 (코로나19 환자 관리 정보시스템 설계)

DDD : Domain Driven Design

사업자 : 다루고자 하는 핵심 비지니스 영역

개발자 : 소프트웨어로 해결하고자 하는 문제 영역

쇼핑몰 - 상품 조회 및 구매 기능 제공

"쇼핑몰 도메인은 상품 조회, 구매, 결제, 배송 등 하위 도메인을 가진다"

 

하나하나의 기능(도메인)이 하나하나의 서비스(마이크로서비스)가 될 수 있다.

 

도메인이란? 해결하고자 하는 문제 영역

 

도메인 주도 설계의 주요 용어

1. 도메인 이벤트 : 발생한 사건

2. 커맨드 : 도메인 이벤트를 트리거하는 명령

3. 외부 시스템 : 도메인 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템

4. 액터 : 개인 또는 조직의 역할

5. 핫스팟 : 의문사항, 결정하기 힘든 사항

6. 에그리거트 : 도메인 이벤트와 커맨드가 처리하는 데이터, 상태가 변경되는 데이터

7. 정책 : 이벤트 조건에 따라 진행되는 결정, "이벤트"가 발생할 때, "커맨드"를 실행한다.

8. 정보 : 엑터에게 제공되는 데이터, 결정을 내리는데 영향을 주는 정보

 

순서

1. 도메인 이벤트 찾기

2. 외부 시스템/외부 프로세스 찾기

3. 커맨드 찾기

4. 액터 찾기

5. 애그리거트 정의

6. 바운디드 컨텍스트 정의

7. 컨텍스트 매핑

 

https://miro.com/

The Visual Collaboration Platform for Every Team | Miro

 

1. 주요 용어 포스트잇 배치하기

2. 도메인이벤트 찾기

• 도메인이벤트는 시간흐름에 따른 시스템의 동작 의미
• 상태의 생성 / 변경/ 삭제가 발생하게 만듬
• 비즈니스 흐름에서 발생한 이벤트에 초점을 맞춰 결정
• 과거 시제 또는 명사형으로 기록 (회원가입되었다 or 회원가입됨)
• 자유로운 의견을 통해 도출된 도메인 이벤트들을 발생 순서를 고려하여 배치

3. 외부시스템을 필요로하는 프로세스를 찾아 도메인 이벤트 뒤에 붙이기

• 명사형으로 작성
• 아이템이 주문되었을 때 결제하는 과정은 외부시스템 이용
• 결제가 승인되었을 경우 외부 이메일 시스템을 통해 결과를 전송

4. 커멘드를 도메인 이벤트 앞에 배치

• 하나의 커맨드에 여러개의 이벤트 발생할 수 있음
• 개발자 입장에서 구현하게되는 API가 됨

5. 핫스팟을 찾아서 배치

• 궁금한 사항이나, 좀 더 논의가 필요한 사항, 결정하기 힘든 사항에 대한 내용을 붙인다.

6. 엑터를 찾아서 배치

• 액터는 사용자 역할을 의미한다.
• 비즈니스를 수행하는 구체적인 역할을 고려해서 도출하도록 한다
• 해당 코로나19 환자 관리 정보시스템 설계는 진단검사, 격리관리팀, 확진자, 역학조사팀 등으로 구분할 수 있다.

7. 문장으로 액터, 커맨드, 이벤트를 검토해보기

• {확진자:액터}가 {치료:커맨드}를 받으면 {치료받음:도메인이벤트} 이벤트가 발생하고, {증상:커맨드}를 통해 {n일이후무증상:도메인이벤트}와 {n일이후유증상:도메인이벤트}가 발생하게 되고 {격리해제:도메인이벤트}라면 {격리해제통보:커맨드}가 실행되어서 {격리해제:도메인이벤트}가 발생된다.

8. 애그리거트 정의

• 애그리거트는 가장 작은 도메인 모델의 모듈 단위이다.
• 커맨드와 도메인 이벤트가 영향을 주는 데이터 요소이다
• 개발자의 입장에서 보면, 도메인의 실체 개념을 표현하는 객체(엔티티)로 구현하게 될 대상이다.
• 커맨드와 도메인 이벤트 사이 상단에 겹쳐서 붙인다

9. 바운디드 컨텍스트를 정의하고 정책을 도출한다.

• 도메인이벤트와 커맨드, 액터, 애그리거트를 고려해서 경계를 식별한다
• 애그리거트의 이름으로 컨택스트 이름을 정의한다. 이 과정에서 동일 애그리거트 중심으로 모듈화가 이루어 진다.
• 정책을 도출해서 붙인다.
• 정책은 이벤트 뒤에 따라오는 반응적인 비즈니스 로직이다.
• 어딘가의 커맨드를 작동시키는 역할을 하기 때문에 도메인 이벤트와 커맨드 사이에 존재하게 된다.

10. 호출 관게의 방향성을 고려하여 컨택스트 매핑을 진행한다

• 바운디드 컨텍스트 간의 관계를 파악한다
• 동기적 호출방식과 비동기적 호출방식을 고려한 표현도 가능하다
• 동기적(실선) : 항상 일관된 데이터 필요, 컨텍스트간 의존도가 높음
• 비동기적(점선) : 결과적 일관성으로 처리가능한 관계
  • 진단검사 컨텍스트 -> 역학조사 컨텍스트 (비동기)
    
    • 진단검사를 수행한 후 양성,음성을 체크하는데 시간이 걸리므로 당일 PCR검사를 한 후 음성 환자만 한꺼번에 역학조사팀으로 연결
  • 접촉자통보시스템 -> 검사대상자 (동기)
    • 밀접촉자는 바로 검사를 받아야하므로 즉시 수행되어야함.

 

 

좀더 간단하게 표현하자면 다음과 같다.

검사실행(커맨드) -> PCR 검사 실행됨(이벤트 발생) -> 검사결과 음성,양성(이벤트 발생) -> 결과에 따른 정책(어딘가에 있는 커맨드 발생)

- 양성인 경우 격리통보(커맨드) -> 환자격리(이벤트 발생) -> 격리정책에 따른 격리

- 역학조사관 파견(커맨드, 비동기) -> 현상확인진행됨(이벤트 발생) -> 동선조사함(이벤트 발생) -> 카드사,통신사(시스템) ->

    밀접접촉자 확인

- 치료시행(커맨드) -> 환자치료(이벤트) 

- 격리해재 통보(커맨드) -> 격리해제됨(이벤트)

- 격리위반여부확인(커맨드) -> 격리위반여부확인(이벤트) -> 사법부(시스템)

 

DDD를 했을 때 느낀점

1. 먼저 바운디드 컨텍스트(격리관리,역학조사..)를 나누지 말자.

2. 도메인 이벤트부터 팀원들끼리 쭉 나열하자.

3. 녹색(정책) -> 파란색(커맨드) 로 연결하자.

4. 보라색(핫스팟)을 많이 남기자.

5. 도메인 지식이 많은 사람이 한명은 있어야 한다. (중요)

6. DDD에 정답은 없다. 이런 프로세스를 할려고 했구나가 이해되고 보이면 된다.

7. 데이터가 구현된다고 치면, 커맨드가 api가 된다. 

8. 데이터베이스를 분리하고 서버도 분리된 상태(데이터가 분리된 상태)에서 직접적으로 데이터를 주고받으면 안됨 (데이터가 오염될 수 있음)

9. 하나의 Funtion(함수)에 하나의 기능을 넣고, 다른 함수에서 똑같은 커맨드가 실행되지 않도록 하자.

    예를들어 환자관리에서 PCR검사를 진행하는데, 격리관리에서 PCR검사를 하는 경우는 없도록 하자.

10. 도메인을 어떻게 나누는가는 내가 시스템을 구현할 때 어떤 식으로 분리를 했을 때 프로세스에 적합한지, 팀 전체가 이해할 수 있는 방향으로 만들기.