◎ 도메인 주도 설계(Domain Driven Design)
도메인 내부에서 문제 해결이 가능한 형태로 도메인을 모델링하는 기법
- 하나의 도메인 모델에 대한 이해관계가 각자 다름을 인정하고
- 각 팀에 적합한 하위 도메인(ex 주문, 배달, 결제 등)을 설정하고
- 해당 하위 도메인에 대한 맥락을 알고 있는 사람이 따라야 할 비즈니스 규칙에 대한 경계를 설정하는 설계 방식
즉 각 클래스로 표현되는 도메인을 기반으로 아키텍처를 설계하는 방법론으로 업무 범위로
bounded context를 구분지어 아키텍처를 구성하는 방법론이다.
※ 도메인 :
지식, 영향력, 또는 활동 영역, 개발 분야에서는 소프트웨어로 해결하려는 문제의 영역을 의미한다.
※ 도메인 지식 :
어떤 산업 또는 분야를 이해하기 위해 필요한 지식
■ 도메인 모델 :
Eric Evans는 도메인 모델이 Value Object, Entity로 표현된다고 했습니다.
여기서 Value object는 도메인에서 한 개 또는 그 이상의 속성들을 묶어서 특정 값을 나타내는 객체를 말합니다.
Entity는 기본 키로 식별값을 갖는 객체를 의미합니다.
즉 도메인 모델이란 Value Object 또는 Entity로 표현되는 서로 '식별 가능한' 경계를 갖는 모델이라고 할 수 있습니다.
이를 통해 서로 의존 관계를 감소시킬 수 있고 전체 서비스에 대한 가용성을 증대시킬 수 있습니다.
■ 도메인 주도 설계시의 주의점
- 도메인 지식을 가진 엔지니어가 팀마다 있어야 한다.
→ 자연스럽게 기능 조직이 아니라 목적 조직화 된다.
여기서 우리는 보편언어(ubiquitous language) 와 한정된 맥락(bounded context)의 개념을 이해해야 한다.
보편언어란 도메인의 특정 업무와 관련된 사람들 사이에서 통용되는 개념으로 각 업무별로 하나의 표현언어를 바라보는 시각이 다름을 표현한 것이다.
쉽게 말해 배달앱에 주문요청이 들어왔다. 결제를 관리하는 팀에서는 이를 '결제'로 인식하지만 배달팀에서는 '배달 요청'으로 인식할 것이다.
한정된 맥락도 비슷한 맥락으로 이해해도 좋다. B라는 영상 업체에서 A라는 기업으로부터 영상 제작을 수주받아 영상을 제작 후 업로드 했다. 여기서 '업로드'라는 행위가 B업체에게는 '납품'이 되겠지만 A기업에게는 '마케팅 활동'이 되는 것이다.
즉 같은 객체로써 인식되어야 할 행위가 다른 객체로써 인식되어지는 것이다.
이러한 중복성을 없애기 위해 도메인 지식을 가진 엔지니어가 업무의 범위를 나눔으로써
각 도메인 모델의 경계를 분명히 구분짓고 해당 업무 범위 내에서만 아키텍처를 구성해야 한다.
- 여러 서비스가 잘 결합할 수 있게 디자인해야 한다.
→ 하지만 동시에 다른 서비스에 지나치게 의존해서도 안된다.
서비스가 분산되어지는 만큼 연결이 매우 중요하다. 결과적으로 효과적인 프로그램을 개발 및 운영하기 위해 이런 설계 방법을 택한 것이기 때문이다.
- 서비스를 오케스트레이션 해야한다.
→ 오케스트레이터는 각 서비스가 죽는지 안 죽는지 여부, 트래픽이 수용 가능한지 아닌지 여부,
인프라 유지보수 (업그레이드, 패치 등) 업무 등에만 집중한다.
◎ 도메인 주도 설계 실습
중앙 방역 본부에 4개의 팀이 존재한다는 가정하에 각 업무를 어떻게 설계하고 연결할 것인지에 대한 실습을 진행했다. 각 4개팀의 목표는 아래와 같다.
■ 환자관리팀
- 양성 판정을 받은 확진자 정보를 등록하고 격리 요청을 보냅니다.
- 격리 기간이 종료된 환자의 증상을 진단합니다.
└ 무증상이고, 호전되는 경우 격리 해제가 가능합니다.
└ 유증상이고, 증상이 호전되지 않을 경우 PCR 검사를 다시 진행해야 합니다.
■ 역학조사팀
- 전자출입명부 및 카드 승인 내역을 기반으로 확진자의 동선을 조사하고, 밀접 접촉자를 확인합니다.
■ 격리관리팀
- 확진자에게 격리 및 격리 해제를 통지하고, 자가격리자가 격리 중에 있는지, 또는 격리 위반을 했는지 확인합니다.
■ 진단검사운영팀
- 선별진료소를 운영하고 PCR 검사를 통해 확진 여부를 파악합니다.아래 포스트잇의 색을 잘 보고 실습과정을 따라오시면 이해가 편합니다!
| 용어 | 내용 |
|---|---|
| 도메인 이벤트 | 발생한 사건 |
| 커맨드 | 도메인 이벤트를 트리거하는 명령 |
| 외부 시스템 | 도메인 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템 |
| 액터 | 개인 또는 조직의 역할 |
| 핫스팟 | 의문사항, 결정하기 힘든 사항 |
| 애그리거트 | 도메인 이벤트와 커맨드가 처리하는 데이터, 상태가 변경되는 데이터 |
| 정책 | 이벤트 조건에 따라 진행되는 결정, “이벤트”가 발생할 때, “커맨드”를 실행한다 |
| 정보 | 액터에게 제공되는 데이터, 결정을 내리는데 영향을 주는 정보 |
1. 도메인 이벤트를 찾아 기록하고 흐름순으로 정리한다.
- 도메인 이벤트는 시간 흐름에 따른 시스템의 동작으로 발생된 어떠한 행위를 동사형으로 기록한다.
2. 외부 시스템을 필요로하는 프로세스를 찾아서 도메인 이벤트 뒤에 붙인다.
- 명사형으로 작성하며 발생한 도메인 이벤트에 적합한 시스템을 선정하는 것이 중요하다.
3. 커맨드를 도메인 이벤트 앞에 배치합니다.
- 커맨드란 도메인 이벤트를 트리거하는 명령으로 구현할 API라고 생각하면 이해가 쉽다.
4. 핫스팟을 찾아서 배치합니다.
- 궁금한사항이나, 좀 더 논의가 필요한 사항, 결정하기 힘든 사항에 대한 내용을 핫스팟으로 정의한다.
5. 액터를 찾아서 배치합니다.
- 비즈니스를 수행하는 사용자의 역할입니다. 해당 업무의 커맨드를 수행하는 수행자라고 생각하면 이해가 쉽습니다.
6. 문장으로 액터, 커맨드, 이벤트를 검토한다.
- 격리기간이 종료된 확진자가 환자 관리팀의 환자 진단을 통해 유증상으로 확인되었고 재검사 요청을 통해 선별검사를 진행하였다. 재검사에서 양성이 판정되어 다시 확진자로 등록되었고 격리 요청을 통해 격리 대상자로 등록되었다.
와 같이 구현한 도메인 설계에 대한 점검을 진행합니다.
7. 애그리거트를 정의합니다.
- 도메인 모델의 모듈 단위로써 기능 즉 작은 업무 단위라고 생각하면 이해가 쉽다.
8. 바운디드 컨텍스트를 정의하고 정책을 도출합니다.
- 설정한 도메인 이벤트와 커맨더, 애그리거트를 고려해서 경계를 식별하는 작업입니다.
- 애그리거트의 범주로 컨텍스트의 이름을 정의하는데 동일 애그리거트 중심으로 모듈화를 진행합니다.
- 이를 통해 정책을 도출합니다. (정책은 커맨드를 작동시키는 역할을 한다는 것을 명심한 후 도출을 진행합니다.)
9. 호출 관계의 방향성을 고려하여 컨택스트 매핑을 진행합니다.
- 컨택스트 매핑은 설계한 프로그램의 전체적인 관계를 축약하여 보여주는 역할을 합니다. 따라서 각 bounded context간의 관계를 잘 파악하여 연결해야 합니다.
- 동기적 관계는 실선으로 표현하며 항상 일관된 데이터가 필요하고 컨텍스트간 의존도가 높을 경우 사용합니다.
- 비동기적 관계는 점선으로 표현하며 결과적인 일관성으로 처리가 가능한 관계일때 사용합니다.
10. 설계한 도메인 모델의 결과를 기록합니다.
