도메인을 한마디로 정의하면 ‘영역’이라 할 수 있습니다.
즉, 전체가 아닌 부분을 가리킵니다.
- 비즈니스 도메인
- 유통
- 이커머스
- 출판
- ···
- 용어 도메인
- 번호
- 주소
- 코드
- ···

도메인 = 전체를 구성하는 한 영역
‘영역’이라는 의미를 염두에 둔다면 ‘도메인’이라는 단어를 들었을 때 의미가 쉽게 와 닿을 것입니다.
도메인의 역할
데이터 표준에서 도메인은 어떤 역할을 할까요?
‘용어(속성/칼럼)의 분류어란 무엇인가요?‘ 글에서 용어의 분류어가 도메인으로 등록한다고 하였습니다.
용어의 분류어를 보면 어떤 값이 들어가는지 예상할 수 있습니다.
- 분류어 예시
- ‘고객동거가족’ + ‘수’
- 함께 사는 가족이 ‘몇 명’ 인지
- ‘고객게시판등록’ + ‘일자’
- 고객 게시판에 ‘언제’ 등록했는지
- ‘상품발송취소’ + ‘사유’
- 상품의 발송을 취소한 ‘이유’가 무엇인지
- ‘고객동거가족’ + ‘수’
위 예시처럼 ‘몇 명’, ‘언제’, ‘사유’는 각각 ‘숫자’, ‘날짜’, ‘문자’ 형식을 가리킵니다.
도메인과 용어의 관계를 도식화하면 아래와 같이 표현할 수 있습니다.

위의 ‘용어 도메인 관계’ 예시는 도메인이 ‘영역’ 이라는 점을 강조합니다.
- ‘고객동거가족수’, ‘주문상품수’의 영역은 ‘수’
- ‘고객게시판등록일자’, ‘고객가입일자’의 영역은 ‘일자’
- ‘상품발송취소사유’, ‘결재반려사유’의 영역은 ‘사유’
만약, 도메인이 없다면 어떨까요?
아래 사진처럼 칸막이 없는 책장과 같을 것입니다.
물론 책을 책장에 넣었으니 책을 보관한다는 목적은 달성했을지 모릅니다.
그러나 책을 보려고 한다면 짜증부터 날 겁입니다!

도메인은 책장의 칸막이와 같습니다.
칸막이가 있다면 책을 분류별로 넣을 수 있지요.
마찬가지로 용어에 도메인을 지정했을 때 용어의 특징을 쉽게 파악할 수 있습니다.
이처럼 도메인은 사용자를 위한 것입니다.

데이터 타입 & 길이
지금까지 도메인을 쉽게 설명하기 위해 매우 단순하게 표현했습니다.
현실세계에서는 훨씬 더 구체적으로 도메인을 구성합니다.
앞의 ‘상품발송취소사유’ 용어를 예로 설명하겠습니다.
해당 용어는 ‘사유’ 분류어를 가집니다.
분류어는 도메인으로 등록한다고 하였습니다.
이때, 어떤 형식의 데이터가 어느 정도 길이의 값을 가지는지를 결정합니다.
만약 문자를 저장할 것이고, 500자만 저장한다면 다음과 같이 정의할 수 있겠지요.
‘사유’ 도메인 = 문자, 500자 → VARCHAR(500)
이처럼 도메인은 데이터 타입과 길이를 가집니다.
한 가지 팁을 드리자면, 너무 다양한 길이를 갖지 않도록 조금 넉넉하게 정의하는 것입니다.
사유 도메인의 길이가 300자, 500자, 1000자와 같이 다양하다면 어떻게 정의하는 것이 좋을까요?
- 방안 1
- 사유 VARCHAR(300)
- 사유 VARCHAR(500)
- 사유 VARCHAR(1000)
- 방안 2
- 사유 VARCHAR(1000)
위의 방안 1과 방안 2 중에서 어떤 안이 좋을까요?
저는 방안 2를 권장합니다.
왜냐하면 방안 1은 도메인의 개수가 늘어납니다.
그런데 늘어난 개수만큼 얻을 수 있는 이득이 크지 않습니다.
방안 2는 도메인 1개로 300자, 500자, 1000자 모두 커버할 수 있습니다.
지금은 과거와 달리 데이터를 굳이 정교하게* 관리할 필요가 없습니다.
* 물론, ‘고객ID’, ‘상품코드’, ‘계약번호’처럼 매우 중요한 속성은 정교하게 관리해야 합니다.
실제 기업에서 도메인을 정의할 때는 유사한 성격의 도메인을 묶어서 상위 도메인을 구성합니다.
이를 도메인그룹이라 합니다.
아래는 도메인그룹과 도메인의 계층 관계를 표현한 예시입니다.

위의 예시처럼 상위 도메인그룹이 하위 도메인을 가지도록 정의할 수 있습니다.
여러 메타 솔루션(Meta#, S-Meta, Big2Core, …)에서 이와 같이 구성할 수 있는 기능을 제공합니다.
도메인이라는 단어가 여기저기 사용됩니다.
이것 하나만 기억해 주시기 바랍니다.
도메인은 영역입니다!