🏷 도메인이란?
도메인은 소프트웨어를 개발하는 대상의 영역으로 쉽게 말하면 우리가 풀어야 하는 문제의 영역이다.
도메인 모델
- 도메인 영역을 해결하기 위한 solution space
- 모든 사람이 도메인을 동일한 관점에서 이해할 수 있고 공유할 수 있도록 단순화시킨 것
지금부터 알아볼 도메인 주도 설계(DDD)는 도메인의 이해를 최우선시하는 모델링 기법이다.
도메인 전문가와 개발자 사이의 커뮤니케이션을 강조하며, 개발자가 구현하기 전 도메인을 깊게 이해하는 것이 핵심이다.
도메인 주도 설계(DDD)의 가장 중요 포인트는, 도메인 전문가와 엔지니어가 함께 참여하는 반복적인 커뮤니케이션을
통해 도메인에 대한 공통의 언어를 구축하는 것이다.
🏷 어떻게 도메인 탐색/언어를 구축할까?
도메인을 탐색하고 언어를 구축할 때 고려해야 할 사항들을 아아보자.
첫번째로 반복적인 커뮤니케이션이 중요하다.
이를 위해 워크샵을 진행하는데,티타임, 식사, 회의 등 최대한 도메인 전문가와 개발자가 자주 커뮤니케이션 하고 문서화 해야한다.
도메인은 새로운 것을 만들어내기 보다는 이미 있는 것을 탐색하고 식별해내는 것이다.
처음부터 완벽한 모델을 얻는 것은 불가능에 가깝기 때문에, 반복적인 탐색 과정을 통해 도메인 모델을 정제해 나가야 비로소 정확한 모델을 식별할 수 있다.
처음 식별된 도메인은 틀릴 확률이 크다는 가정하에 일을 진행하면서 반복적으로 재검토, 개선해나가야 한다.
워크샵
- 유비쿼터스 언어를 정의하고 서브 도메인을 식별하기 위한 과정
- 워크샵에는 도메인 전문가, 제품 책임자, 개발자 등 다양한 이해 관계자 참석 필수
- 우리가 만들려는/운영하고 있는 시스템에 대해서 깊이 있게 논의해보며 언어를 맞추어 나가야 함
🏷 전략적 설계
전략적 설계는 도메인 주도 설계의 세부 개념 중 하나로, 마이크로서비스 도출을 위해서 비즈니스 상 전략적으로 중요한 것을 찾아 중요도에 따라 이를 나누는 단계이다.
✔️ 전략적 설계의 두 가지 주요 개념
- 프로젝트를 수행하는 모든 팀원이 공통으로 사용하는 유비쿼터스 언어
- 도메인의 주요 개념을 정의하고 도메인 간의 경계를 식별하는 바운디드 컨텍스트
🏷 서브 도메인
전체의 비즈니스 도메인을 이해 가능한 하위 영역으로 분리해야 한다.
전체의 큰 도메인을 분리한 것을 서브 도메인이라 한다.
거대한 전체 비즈니스 도메인을 핵심 서브도메인, 지원 서브도메인, 일반 서브도메인으로 분리할 수 있고,
서브도메인을 식별하는 과정을 통해 도메인의 우선순위화가 가능하다.
✔️ 핵심 서브도메인
핵심 서브도메인은 다른 경쟁자와 차별화를 만들 수 있는 비즈니스 영역이다.
프로젝트 목록에서 높은 우선순위를 가지며, 소프트웨어 개발에 있어서 전략적으로 가장 큰 투자가 필요한 부분이다.
✔️ 지원 서브도메인
지원 서브도메인은 비즈니스에 필수적이지만, 핵심은 아닌 도메인이다.
그러나 지원 서브도메인 없이는 핵심 도메인을 성공시킬 수 없다.
핵심 서브도메인 다음으로 중요한 도메인이다.
✔️ 일반 서브도메인
일반 서브도메인은 시스템에 필요하긴 하지만 큰 공수를 들일 필요는 없는 도메인이다.
가장 중요도가 낮고, 아웃소싱으로 개발하거나 기존 제품의 라이센스 구입 후 사용 가능하다.
🏷 바운디드 컨텍스트
✔️ 바운디드 컨텍스트
바운디드 컨텍스트는 의미적으로 동일한 맥락의 경계 또는 범위를 뜻하고, 유비쿼터스 언어로 표현된다.
의미적으로 동일한 맥락의 경계라는 것은, 그 범주 내에서 소프트웨어 모델의 각 컴포넌트가 특정한 의미를 갖고 그 특정한 일을 한다는 것을 의미한다.
바운디드 컨텍스트마다 각각 분리된 소프트웨어의 코드를 산출한다.
✔️ 서브 도메인과 바운디드 컨텍스트의 관계
서브 도메인은 Problem Space, 바운디드 컨텍스트는 Solution Space 이다.
- Problem Space : 해결해야 하는 도메인 - 서브 도메인들의 집합
- Solution Space : 해결책을 실제 구현 - 바운디드 컨텍스트들의 집합
보통 하나의 서브도메인은 하나의 바운디드 컨텍스트를 갖고 있으며
서브도메인이 하나 이상의 바운디드 컨텍스트에 매핑될 수 있다.
🏷 유비쿼터스 언어와 바운디드 컨텍스트
SW 개발의 가장 큰 문제 중 하나는 언어의 통일이다.
제품 책임자와 도메인 전문가 그리고 개발자 간 언어의 통일이 중요하다.
언어는 문맥 안에서 서로 다르게 이해될 수 있다.
예를 들어, 쇼핑몰 사이트를 개발하고 있다고 가정해보자.
- 카탈로그 문맥에서의 상품
- 재고 관리 문맥에서의 상품
- 주문 문맥에서의 상품
- 배송 문맥에서의 상품
같은 상품이라고 해도, 위와 같은 경우에서는 다르게 이해될 수 있다.
컨텍스트에 따라 비슷해 보이는 언어들이 실제로는 다를 수 있고, 같은 상품이지만 컨텍스트에 따라 필요한 데이터가 다르다.
따라서 각 문맥 별로 상품의 이름을 명확하게 재정의할 필요가 있다.
- 카탈로그 컨텍스트에서의 상품은 Product
- 재고 컨텍스트에서의 상품은 Stock
- 주문 컨텍스트에서의 상품은 OrderedItem
도메인 주도 설계에서는 비슷하지만 서로 다른 개념들을 각기 다른 바운디드 컨텍스트 내부로 분리한다.
이는 개념 간 차이를 명확하게 해주고, 명확하게 재정의된 개념들은 각각의 바운디드 컨텍스트 내부의 유비쿼터스 언어가 된다.
🏷 컨텍스트 매핑
복잡하고 큰 도메인을 여러개의 바운디드 컨텍스트로 분할하게 되면 각 바운디드 컨텍스트 간에 협업이 필요하게 된다.
컨텍스트 매핑은 바운디드 컨텍스트들 간의 협업을 위한 패턴들을 정의하는데 이는 마이크로 서비스간의 협업과도 같은 개념이다.
여러 개의 바운디드 컨텍스트들은 비즈니스의 문제 해결을 위해 상호 간에 연동이 필요하고,
컨텍스트 매핑에서 두 바운디드 컨텍스트 사이의 선이 어떤 종류의 관계인지를 찾는 것이 중요하다.
🏷 이벤트 스토밍
이벤트 스토밍은 DDD의 설계를 빠르게 진행할 수 있는 도구이다.
알베르토 브란톨리니가 DDD의 빠른 설계를 위해 고안한 방법으로, 아주 큰 벽이 있는 회의실/포스트잇/전지/실테이프 등을 이용하여 가볍게 진행할 수 있다.
유사한 것들을 묶고, 다른 것들과의 경계를 찾아 바운디드 컨텍스트를 식별한다.
바운디드 컨텍스트 간의 관계를 찾아 표시해서 컨텍스트 맵을 작성하고,
최종적으로 dependency나 transaction의 관계를 고려해서 후보 마이크로 서비스를 식별한다.
🏷 요약
-
DDD는 비즈니스에 대해 도메인 전문가와 개발자들의 도메인의 이해에 대한 눈높이를 맞추는 것이 중요하다.
➡️ 유비쿼터스 언어를 개발하여 사용함으로써 도메인 전문가와 개발자 사이에 도메인을 이해하는데 오해를 줄일 수 있다. -
전략적 설계에 따라 비즈니스의 영역을 우선순위화하여 핵심에 집중할 수 있게 된다.
➡️ DDD를 적용해서 비즈니스의 복잡한 문제를 잘 해결할 수 있는 올바른 소프트웨어를 만드는데 도움을 받을 수 있다.
