Domain Driven Design 에서 말하는 '도메인'(Domain)을 사용하지만, 실무에서도 업무의 구분 등의 목적으로 '도메인' 이라는 용어를 자주 사용합니다.
시스템 혹은 회사의 비지니스를 잘 안다고 가정한다면, SW Arch. 관점에서 Biz. 상세하게 구조화 하고 분류 해야 할 필요가 있습니다.
이 단위가 도메인이라고 생각하면 될 것 같습니다.
20년째 제가 운영/개발을 하고 있는 통신 Biz. BSS 시스템에서도 도메인이라는 용어를 사용하고 있었습니다.
"오더, 상품, 청구, 수납, 자원 등등.. " 또는 쇼핑몰 시스템이라면 "회원(고객)관리, 상품관리, 주문/계약, 파트너 관리 .. " 역시 이미 내부적으로 기능의 응집도와 결합도를 고민해서 나름의 작은 덩어리를 만들어서 사용하고 있을 겁니다.
DDD를 관점에서 기존 System을 다시 현대화(Modernization) 하겠다고 생각해보겠습니다.
저도 최근에는 BSS(Business Supporting System) 시스템을 Onpremise > Cloud 의 전환을 고민하고 준비하고 있습니다.
DDD에서 말하는 '도메인'의 정의를 다시한번 확인하고 나의 System은 잘 구조화 되었는지, 어떻게 도메인을 다시 정의할지 알기 위해서 "도메인"의 개념에 대해서 알아보고자 합니다.
비지니스 도메인 ( Business Domain )
비지니스 도메인은 기업의 활용을 정의하는데, 회사가 고객에세 제공하는 서비스라고 볼수 있습니다.
- 스타벅스는 커피/음료를 판매합니다.
- SKT는 통신서비스를 제공합니다.
- 교보문고는 서적 판매 합니다.
하위 도메인 (Sub Domain)
비지니스 도메인을 조금 더 세분한 한 영역을 말하며, 기업이나 시스템은 하위 도메인(Sub Domain)을 통해서 고객에게 서비스를 궁극적으로 제공(비지니스 도메인)한다고 생각하면 됩니다.
하위 도메인은 다시 3가지 형태로 분류 됩니다.
- 핵심 (하위)도메인 (Core Subdomain)
- 일반 (하위)도메인 (Generic Subdomain)
- 지원 (하위)도메인 (Supporting Subdomain)
핵심 (하위)도메인 ( Core Subdomain )
회사가 경쟁력을 가지고 경쟁업체와 다르게 수행하며 복잡하고 구현이 어렵습니다. 즉, 경쟁력있는 비지니스를 위해서 비용절감, 프로세스 최적화 등 나름의 방법으로 최적화 하고 있는 영역입니다.
당연히 복잡도는 높고, 진입 장벽도 높고 다른 회사가 솔루션을 쉽게 모방하기 어려워야 할 것 입니다.
구글에 검색이 그러하고 우버의 차량배차 및 손닙 매칭 영역이 그렇다고 볼 수 있습니다.
핵심 도메인은 반드시 알고리즘, 기술, 솔루션이 아닐 수 있습니다. 의류 디자인 회사의 핵심은 디자이너의 디자인 능력일 수 있습니다.
또한, 비지니스의 환경이 변하고 비지니스 도메인이 바뀌면 핵심 도메인도 일반 도메인 될수 있고, 일반 도메인이 핵심 도메인으로 되기도 합니다.
일반 하위 도메인 (Generic Subdomain)
모든 회사가 유사하게 수행하는 비지니스 활동이며, 복잡하고 구현이 어렵습니다.
그러나 핵심과 다른 점은 다른회사와 비교우위나 경쟁력을 제공 하지 않습니다. 그렇기 때문에 이미 많은 회사가 검증해서 사용하는 솔루션을 사용하거나, 더 이상의 혁신이나 최적화가 불필요 할 수 있습니다.
예를들어, 보안/인증 기능은 이미 검증된 특정 기술/솔루션을 통해서 수행하여 경쟁업체와 경쟁우위를 가질 필요 없습니다.
지원 하위 도메인 (Supporting Subdomain)
말 그대로 비지니스 지원이며 경쟁업체와 비교 우위를 가질 필요 없습니다. 하지만 일반 도메인과 다르게 솔루션이나 로직이 복잡하지 않습니다. 대부분 데이터 입력/변환/추출 작업이거나, CRUD 인터페이스 형태라고 보시면 됩니다.
어떠한 경쟁우위도 필요없고, 로직도 복잡하지 않기 때문에 대부분 이미 제공하는 솔루션을 사용 하는 것을 선호 합니다.
하지만 실제 구축이 간단하고 저렴하면 직접 구축하기도 합니다.
핵심 도메인이 정의가 중요!
이제는 실제 하위도메민을 구분하고 유형을 식별 해야 합니다.
처음에 하위 도메인을 크게 나눕니다.
예를들어 "고객관리, 상품관리, 청구관리, 수납관리.." 로 나누었지만 실제 상세 기능으로 더 세분하면 그 내부에도 일반/핵심/지원 으로 분류 될 세부 기능들이 나옵니다. 그렇기 때문에 하위 도메인의 경계선정이 중요합니다.
그 방법은 하위 도메인 내부 "유스 케이스"를 세분화 해서 정의 하는 것입니다.
예를 들어, 오더관리에는 "이동전화 신규 가입, 명의 변경, 이동전화 번호 변경 등 " 다앙햔 유스케이스가 있습니다.
핵심 도메인의 경우 이런 유스 케이스를 자세히, 신경써서 도출해야 합니다. 그에 반해 일반/지원 도메임의 경우 핵심 도메인 보다 적당히 도출 해도 무방합니다.
일반/지원의 경우 갱쟁력이 중요한 부분이 아니니까요.
'Software Engineering' 카테고리의 다른 글
| OpenAPI Specification(OAS) : API 문서화의 게임 체인저 (3) | 2025.06.25 |
|---|---|
| [DDD]바운디드 컨텍스트(Bounded Context)란? (0) | 2024.03.09 |
