DDD의 기본 개념에 대해 알아보았던 DDD란 무엇인가(1) 에 이어서 이번 글에서는 DDD에서 많이 사용하는 용어들에 대한 정리를 해보고자 합니다. 회사 프로젝트에서 타회사 AA(Application Architecture) 분들과 설계 단계에서 대화를 나눌 때 많이 접했던 용어들과 그분들이 설명해주셨던 대로 정리해보고자 합니다.
개인적으로 해당 부분은 개발자들의 영역이기보다는
비즈니스 정책을 정하는 현업분들(또는 기획자)의 의견이 필요한 영역이라고 생각합니다.
도메인
- 도메인은 외국 용어이기도 하고 딱히 해당 용어를 우리말로 번역할 만한 단어가 없는 것 같습니다. 도메인은 우리가 해결하고자 하는 문제 영역이라고 볼 수 있습니다. 그냥 '네이버', '쿠팡' 처럼 서비스 자체를 도메인이라고봐도 됩니다.
서브 도메인
- 서브 도메인은 '도메인'을 하위 도메인으로 나눈 것입니다. 예를 들어 이커머스 서비스 라는 큰 도메인이 있다면 그 하위에 '주문', '배송', '결제', '쿠폰', '회원' 등과 같은 것들이 하위 도메인, 즉 해당 서비스 도메인을 구성하는 '서브 도메인'이 될 수 있습니다.
바운디드 컨텍스트
- 바운디드 컨텍스트는 모델의 경계를 결정하며 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 갖게 됩니다.
바운디드 컨텍스트는 용어를 기준으로 구분하게 되는데 예를들어 시스템을 사용하는 사람을 회원 도메인에서는 회원이라고 부르지만, 주문 도메인에서는 주문자라고 부르고, 배송 도메인에서는 보내는 사람이라고 부르기도 합니다.
이렇게 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다르기 때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수도 없습니다.
모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖게 됩니다. 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 서로 다릅니다. 이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 BOUNDED CONTEXT 라고 부릅니다.
또 한 가지 예를 들어 게임 서비스 에서 '게임 캐시로 아이템을 사는 경우'를 가정해볼 수 있습니다.
이 과정에서 개입하게 되는 도메인은 두 개의 도메인이 있을 수 있습니다.
한 부분은 '게임 개발' 파트,
다른 한 부분은 '결제 개발' 파트입니다.
아마 게임 내부에서 아이템 구입 행위가 일어난다면,
'게임 개발'에서는 아이템의 구매적인 측면을 중심적으로 생각할 것입니다.
이 아이템이 어떤 것인지, 어떤 가치를 가지고 어떠한 기능이 있는지에 대해서 인지하고 있을 것입니다.
또한 구매가 이루어졌을 때, 인벤토리로 꽂아주는 기능 등을 고려해야 합니다.
반면, '결제 개발'에서는 이 아이템이 무엇인지, 그리고 게임 내적으로 어떤 데이터들을 다뤄야 하는지에 대해서는 전문성과 지식이 없습니다. 오히려 결제가 전반적으로 문제없이 진행되는지, 실제 결제 벤더사들(PG사, 카카오페이와 같은 페이 서비스와의 연동)과의 문제가 없는지에 더 초점을 맞출 것입니다.
이렇게 두 개발팀에서는 같은 데이터에 대해서 해석이 다릅니다.
아마 내부적으로 각 팀에서 사용하는 용어도 다를 것입니다.
게임 쪽은 게임 도메인에서 사용하는 용어가 익숙할 것이고, 결제는 그렇지 않을 것입니다.
두 팀이 아이템 구매에 대해서 같은 RDB 테이블을 사용한다고 하면, 각자 필요한 Column을 추가해야 할 것입니다.
또는 힘이 쎈 팀이 DB에 대해서 주도권을 가져갈 수도 있고...
이렇게 같은 데이터와 행위에 대해서 각 팀마다, 도메인마다 데이터 모델을 다루는 방식이 다루기 때문에,
이런 맥락이 충분하게 구분되어야 합니다.
이런 맥락(Context)을 나누는 것이 바로 '바운디드 컨텍스트'입니다.
각 팀에서 필요한 데이터들은 그 모양과 처리 방법이 다르기 때문에, 이를 경계로 나누겠다는 것입니다.
게임팀에서는 게임에 관련된 데이터를 따로 관리하고, 결제팀에서는 결제에 관련된 데이터를 따로 관리합니다.
데이터 저장의 흐름에 대해서는 팀끼리 조율하며, 서로의 데이터를 자신에게 맞도록 하기 위해 변환을 하기도 합니다.
유비쿼터스 언어
유비쿼터스 언어(Ubiquitous Language) 각 팀에서 사용하는 실제의 비즈니스 용어를 뜻합니다.
바운디드 컨텍스트를 나누는 과정에서는, 이러한 유비쿼터스 언어도 정해야 합니다.
각 팀에서 사용하는 용어를 일치시키는 과정입니다.
게임 팀에서 사용되는 구매와, 결제 팀에서 사용되는 '구매'가 아예 사용되는 단어가 다를 수가 있습니다.
게임에서는 '아이템 구매'
결제에서는 '상품재화 또는 현금 캐시 구매'
라고 읽고 싶을 수가 있는 것이며,
또 한 가지 예를 들어 본다면 카탈로그 도메인에서의 상품, 재고 관리에서의 상품, 주문에서의 상품, 배송에서의 상품은 이름만 같이 실제로
의미하는 것이 다를 수 있습니다. 카탈로그에서의 상품은 상품 이미지, 상품명, 상품 가격, 옵션 목록 과 같은 상품 정보가 위주라면, 재고 관리에서의 상품은 실존하는 개별 객체를 추적하기 위한 목적 상품을 뜻하는 것일 수 있습니다. 즉 카탈로그에서 물리적으로 한 개인 상품이 재고 관리에서는 여러 개 존재할 수 있습니다. 이러한 것들을 다 각자의 도메인에 맞게 정하는 것입니다.
또한 유비쿼터스 언어에서 결정해야하는 것은 각 컨텍스트간의 용어 분리뿐이 아닙니다.
사실 각 팀의 개발자와 도메인 전문가(기획자, 현업), 그리고 AA(Application Architecture)의 용어의 괴리도 상당한 편입니다.
AA와 현업에서 정한 용어를 개발자가 개발하면서 그 의도대로 받아들이지 못하는 경우도 발생할 수 있습니다.
개발자들은 개발 용어로 설명하는 것을 편하게 생각하기 때문에, 그리고 도메인보다는 프로그래밍적으로(아키텍처나 코드 측면) 생각하기 때문에 문제가 생길 수 있습니다. 이러한 것들도 유비쿼터스 언어를 정하는 과정에서 충분한 협의가 필요합니다.
참고 : https://appleg1226.tistory.com/41
(2) DDD의 도메인과 바운디드 컨텍스트 - 개발보다는 설계부터!
도메인과 바운디드 컨텍스트는 무엇이길래 이전 글에서도 이야기 했지만, DDD는 용어부터가 우리가 알고있는 것과 다르고, 익숙해져야 할 것들이 많다. 특히나 바운디드 컨텍스트(Bounded Context)에
appleg1226.tistory.com
책 : DDD START! , 마이크로서비스 도입 이렇게 한다
'BackEnd > DDD' 카테고리의 다른 글
| DDD - 애그리거트 (1) | 2023.02.04 |
|---|---|
| DDD란 무엇인가(1) (0) | 2022.10.23 |