도메인 주도 설계란?

도메인을 중심에 놓고 설계하는 방식

• 유비쿼터스(ubiquitous) 언어의 사용. 도메인 전문가와 개발자 구성원이 상호가 이해할 수 있는 모든 문서와 코드에 사용되는 동일한 표현 및 언어를 구축하는 과정을 말합니다. 설계부터 구현까지 통일된 표현으로 커뮤니케이션이 가능합니다.

• 소프트웨어 엔티티와 도메인 컨셉을 항상 함께 움직이는 구조의 모델로써 가능한 가까이 일치시키는 것.

• DDD는 전략적 설계와 전술적 설계으로 나눌 수 있습니다. 전략적 설계는 개념 설계이고 전술적 설계는 프로그래밍하기 위한 구체적 설계라고 할 수 있습니다.

도메인에 대한 이해는 매우 중요합니다.
도메인에 대한 이해가 있으면 내가 속한 프로젝트를 넘어 회사가 활동하는 분야가 어떤 것인지, 회사가 추구하는 목표가 무엇인지 등을 파악하고 있다는 말과 같습니다. 따라서 도메인에 대한 이해가 있으면 개발이 편해집니다.

이전에 CQRS 글을 쓰면서 전술적 설계를 하였기 때문에 이번에는 전략적 설계만 설명해 보도록 하겠습니다.

이벤트 스토밍

이벤트 스토밍은 포스트잇을 붙이는 방식으로 진행합니다.
Aggregate, Command, Event 등등 서로 다른 색상의 포스트잇으로 붙입니다.
만약 오프라인에서 진행을 한다면 짧은 시간동안 적극적인 진행을 하기 위해 모두 서서 진행합니다.

Pivotal에서 진행을 한 이벤트 스토밍을 보면서 설명을 하겠습니다.

Command

• 파란색 포스트잇은 커맨드를 의미합니다.
• 커맨드는 주로 요청을 의미합니다.
• 이벤트를 발생시키는 명령어

Event

• 주황색 포스트잇은 이벤트를 의미합니다.
• 사용자 생성링크 선택 이라는 커맨드가 만들어졌기 때문에 사용자의 생성정보가 입력되었다는 이벤트가 발생하였습니다.
• 이벤트는 주로 상태변경, 알림에 쓰입니다.
• 도메인에서 발생할 수 있는 모든 사건들을 과거형으로 작성하는 것이기 때문에 과거형 수동형 문장으로 씁니다.

External System (외부 시스템)

• 핑크색 포스트잇은 외부 시스템을 의미합니다.
• 메일 서버가 회사 내부에 구현되어 있더라도, 현재 서비스의 외부에 있다면 외부 시스템이라고 여깁니다.

Aggregate

• 노란색 포스트잇은 Aggregate를 의미합니다.
• Aggregate는 “무엇”이 커맨드를 처리하고 이벤트를 발생시키는 범위를 말합니다.
• 쉽게 말해 큰 카테고리로 분류할수 있으면 그것이 Aggregate입니다.

Issue (핫스팟)

• 보라색 포스트잇은 이슈를 의미합니다.
• 다른 포스트잇에 대한 의문사항 및 논의사항입니다.
• 대표적으로 이뤄지는 논의 주제는 용어 정의가 있습니다.

이벤트 스토밍에 참여한 구성원들은 서로 다른 이해도를 가졌고 서로 다른 직무를 가지고 있습니다.
그렇기 떄문에 서로가 사용되는 용어들이 다르고, 같은 용어라도 다른 뜻으로 받아들일 수 있습니다. 이러한 논의 과정을 거쳐 참여자 모두 같은 용어를 사용하게 되고, 도메인에 대한 이해도가 깊어집니다.

이러한 과정을 통해 참여자들이 공통적으로 사용하는 용어집이 생깁니다. 이러한 용어들을 모아 유비쿼터스 언어라고 부릅니다. 이벤트 스토밍을 진행하면 구성원 모두가 동일하게 사용하는 유비쿼터스 언어를 구축할 수 있습니다.

바운디드 컨텍스트

포스트잇으로 Aggregate 설계가 전부 되었으면 바운디드 컨텍스트 단계를 수행합니다.

바운디드 컨텍스트는 특정 도메인 모델에 속하는 문맥들을 묶어주는 작업입니다.
바운디드 컨텍스트의 의미를 이해하기 위해서는 먼저 도메인과 서브도메인의 개념을 이해해야합니다.

• 도메인 : 소프트웨어 개발을 통해 해결하고자하는 전체 문제 영역을 의미.
• 서브도메인 : 전체 도메인을 풀고자하는 문제의 특성에 따라 나눈 것.

ex) 은행 거래 시스템을 개발한다면, 은행 거래 도메인은 사용자 정보 관리, 계좌, 거래 기록, 입출금 관리 등의 서브 도메인으로 나눠질 수 있습니다.

바운디드 컨텍스트는 서브도메인의 문제를 해결하기 위한 해결책의 범위입니다. 따라서 각 바운디드 컨텍스트를 한 팀에서 개발 및 관리를 합니다. 하나의 팀이 여러개의 바운디드 컨텍스트를 가질 수도 있지만 가장 이상적인 것은 하나의 팀이 하나의 바운디드 컨텍스트를 가지는 것입니다.

바운디드 컨텍스트마다 동일한 용어라도 다른 의미를 가질 수 있습니다. 또한 같은 개념이라도 바운디드 컨텍스트마다 다른 용어로 표현될 수도 있습니다. 예를들어 주식이라는 개념이 주식 바운디드 컨텍스트에서는 주식이라고 불리지만, 주문 바운디드 컨텍스트에서는 상품이라고 불릴 수 있습니다.

컨텍스트 맵

• 컨텍스트 맵은 바운디드 컨텍스트 간의 관계를 표현하는 것입니다. 때문에 방향 표시가 중요합니다.
• 위의 사진의 컨텍스트 맵은 컨텍스트 맵을 표기하는 여러 방법중 하나인 보리스 다이어그램 입니다.
• 보리스 다이어그램에서는 비동기와 동기를 구별해서 표기하는데 빨간줄은 비동기 호출, 파란 줄은 동기 호출을 나타냅니다.

• 실제 컨텍스트 맵은 이렇게 생겼습니다.
• 업스트림과 다운스트림으로 구성이 되어있는데 방향을 표시하는 것입니다. (U -> D)

Snap-E

• 마지막 단계인 Snap-E 입니다.
• Snap-E에서는 포스트잇 색상의 의미가 이전 단계들과 다릅니다.
• 실제 API, DATA 등 표기해둔 문자로 구분합니다.
• 서비스에 대한 상세 스펙 즉 API 목록과 유저 흐름 등을 정리해둘 수 있게 됩니다.

그 외 용어

• Actor: 커맨드를 내리는 주체, 어떤 명령들은 시스템이나 정책 등에 의해 자동으로 내려지기도 하므로, 모든 커맨드에 액터가 필요하지는 않습니다.

• Policy: 어떤 이벤트가 발생하면, 다른 커맨드가 연달아 발생해야하는 경우가 있습니다. 이벤트로부터 새로운 커맨드를 생성합니다.
  실제 구현 시에는 정책이 도메인 이벤트 핸들러가 됩니다. 도메인 이벤트가 발생하면 핸들러에 의해 정책이 실행되고, 정책은 새로운 요청을 실행시킵니다.

온라인에서 이벤트 스토밍을 해보자

이벤트 스토밍을 온라인에서 진행할 수 있도록 툴을 제공하는 사이트입니다.
https://www.msaez.io/

느낀 점

이번에 DDD의 전술적 설계를 공부하면서 이벤트 스토밍이 너무나도 마음에 들었습니다.
이벤트 스토밍을 하게 된다면 얻을 수있는 가치들이 너무나도 많았습니다.
진짜 이벤트 스토밍을 한 이후에는 개발을 어떻게 해야될지 바로바로 보이기 때문에 설계 덕분에 개발이 너무 편해질 것 같습니다.

또 실제로 프로젝트 개발을 진행하면서 용어가 달라서 개발할때 불편함이 있었던 경우가 종종 있었는데 이벤트 스토밍을 하게 된다면 이러한 문제를 해결하기 쉬울 것 같습니다.

제가 프로젝트를 처음부터 개발을 하게 된다면 꼭 팀원들한테 이벤트 스토밍을 하자고 제안을 하고 싶습니다.