✅ 도메인 주도 설계란?
-
구축해야 하는 소프트웨어, 시스템 위해서는 문제를 이해해야 함
-
문제 : 그 조직의 비지니스 전략과 소프트웨어를 통해서 얻고자 하는 가치를 의미
-
문제를 이애하려면 그것이 존재하야 하는 맥락을 이해해야 한다.
-
비지니스 도메인이란?
- 기업의 주요 활동 영역, 회사가 제공하는 서비스
-
하위 도메인 (Sub Domain)
- 비지니스 활동의 세분화된 영역, 제공하는 서비스 단위
✅ Sub Domain (하위 도메인) 유형
-
핵심 (Core)
- 회사가 경쟁업체와 다르게 수행하고 있는 것
- 복잡성 높지만 Biz 경쟁력 제공
- Ex) 우버의 방향에 따른 손님 매칭 서비스, 구글의 검색 순위 알고리즘
-
일반 (Generic)
- 모든 회사가 같은 방식으로 수행하는 비지니스 활동
- 복잡하고 구현하기 어려우나, 경쟁력을 제공하지는 않음. 알려진 영역
- Ex) 인증 , 권한 부여
-
지원 (Supporting)
- 회사 비지니스 지원 활동
- 기능 간단, 어떠한 경쟁우위 제공하지 않음
- CRUD, ETL
✅ 하위 도메인 유형에 따른 구현 방법
-
핵심 (Core)
- 사내에서 구현, 조직의 핵심 숙련 인재 할당
- 자주 지속적으로 변경 예상되므로 가장 진보된 엔지니어링 기술 적용
-
일반 (Generic)
- 이미 만들어진 제품, 오픈 소스 솔루션
-
지원 (Supporting)
- 사내에서 구현하지 않음
- 정교한 디자인 패턴이나 고급 엔지니어링 기술 필요 없음
- 새로운 인재 양성을 위한 연습 기회 제공
✅ 멘탈 모델과 도메인 지식
- 도메인 지식 ⇒ 도메인 전문가가 문제를 생각하는 방식, 즉 멘탈 모델
- 문제를 해결하기 위해서는 문제를 이해해야 함
- 기존의 과정에서는 변환의 과정을 거침
- 도메인 주도 설계에서는 도메인 지식을 변환하는 대신 도메인을 설명하기 위한 단일화된 체계 ⇒ 유비쿼터스 언어
- 기술 용어 X, 비지니스 도메인에 관련 된 용어
✅ 유비쿼터스 언어
- 정확하고 일관성 있어야 한다.
- 모호한 용어 (X)
✅ 도메인 모델
- 효과적인 모델은 그 목적을 달성하는 데 필요한 세부사항만 포함한다.
- 실 세계의 복사본이 아니라 문제를 해결하려는 의도가 있으며, 그 목적에 필요한 정보만 제공해야 한다.
- ‘All models are wrong, some are useful’
- 모델은 본질적으로 추상화의 결과 이다.
- 모델로써 실 세계의 복잡성을 관리
- 도메인 모델링 : 유비쿼터스 언어로 사실상 비즈니스 도메인 모델을 구축하는 것
- 명사와 행위 파악
- 모델이라는 개념은 모든 데이터한 부분을 표현하지 않는다.
- 지하철 노선도처럼 실제는 매우 복잡하게 꼬불꼬불하겠지만
- 지하철 노선도를 표현할 때는 상황에 따라 필요한 정보만 제공해주도록 한다.
- 추상화된 사실과 부합되지 않는 표현을 함으로써 우리가 얻고자 하는 목적을 달성할 수 있다.
✅ 진흙 덩어리
- 소프트웨어 복잡성은 본질적인 도메인 복잡함과 우발적인 기술 복잡성의 혼합의 결과물
- ex) 거대한 ERD
- 멘탈 모델을 Domain으로 표현하는건 좋은데, 도메인이 너무 거대하게 발전하게 하지 말고, 쉽게 하기 위해서는 BC 별로 Domain을 나눠야 한다.
✅ Bounded Context (바운디드 컨텍스트)
- 모델의 경계
- 바운디드 컨텍스트는 유비쿼터스 일관성이 유지되는 경계
- 유비쿼터스 언어의 용어, 원칙, 비지니스 규칙은 해당 바운디드 컨텍스트 내에서만 일관성이 있다.
- 유비쿼터스 언어로 표현된 Customer는 BC에 따라서 각기 다르게 해석이 된다.
- Delivery 에서의 Customer이라는 유비쿼터스 언어는 배송 받는 사람이라는 개념을 갖고 있다.
- 배송이라는 Context 안에서 Customer는 배송이라는 업무를 처리하는데 있어서 어떤 일관성이 있다. (개념의 일관성이 있다.)
BC 안에서만 그 의미가 있다.
✅ Bounded Context 와 Domain Model
-
Domain Model
- 특정 도메인을 개념적으로 표현한 것
- 도메인의 핵심 규칙을 구현
-
BC가 이후 세분화될 가능성이 있다.
- 컴포넌트 개발 생명주기 분리할 필요가 있거나
- 기능이 독립적으로 확장해야 할 경우
-
각가의 BC의 생명주기는 독립적
- 물리적 경계 역할, 소유권 경계
-
Bounded Context 와 하위 Domain의 차이
- 하위 Domain은 비지니스 전력에 의해 정의 됨, 반면에 Bounded Context는 소프트웨어 엔지니어에 의해 설계 됨
- 하위 Domain은 발견되고, Bounded Context는 설계한다는 점
-
BC의 생명주기는 다른 BC와는 독립적이다.
-
유비쿼터스 언어는 BC내에서만 고유하다.
-
유비쿼터스 언어는 BC에 따라서 다르다.
✅ 도메인 모델을 위한 도메인 개념의 이해
- Customer의 개념은 맥락(BC)에 따라 다를 수 있다.
- 해당 되는 맥락에서 의미 있는 도메인 개념을 식별하여 모델링한다.
- 주문할 때 Buyer라는 개념, 배송 받는 사람은 수취인 Recipient 이라는 개념으로 한다.
- 주문할 때나 수취할 때 굳이 Customer를 호출하지 않아도 가능하다.
- 독립적으로 처리할 수 있게 해준다.
- BC에 필요한 그런 요소들로 가져와야 한다.
- 필요한 개념들을 별도로 정의를 하는 것이다.
✅ Context Mapping (컨텍스트 매핑)
- BC는 서로 독립적으로 발전할 수 있지만, 상호작용 해야 한다.
- 즉, 각 BC는 접점이 있다.. 이를 Contract라 한다.
- BC의 연동, 통합 : 각 바운디드 컨텍스트에서 작업하는 팀간의 관계를 의미하기도 한다.
- 협력형 - 패턴 그룹
- 사용자 - 제공자
- 분리형 노선
- 각각의 유비쿼터스 랭귀지간에 번역이 필요하다 (통역, 번역)
- 각각의 BC에서 유비쿼터스 랭귀지를 가지고 결제 Context 에서는 결제자를 개념화
배송 Context에서는 수취자라는 개념을 모델링 했다. - 이 2가지의 다른 개념들을 번역하고 통역할 수 있는가를 (Context Mapping)을 통해서 규정한다.
참고
Go For It