비즈니스 도메인 분석: 어디에 설계 노력을 쓸 것인가

비즈니스 도메인은 조직이 가치를 만드는 활동 영역이다. 배송 회사의 도메인은 물류, 온라인 쇼핑몰의 도메인은 상품 판매일 수 있다. 조직 하나가 여러 도메인을 운영하기도 한다. 분석의 목적은 조직도를 코드의 패키지에 복사하는 것이 아니라, 서로 다른 업무 문제와 경쟁 우위의 원천을 찾는 데 있다.

하위 도메인을 찾는 순서

온라인 식료품 판매를 가정해 보자. ‘주문 받기’ 하나로 시작하면 재고 예약, 배송 시간 배정, 결제 정산의 규칙이 뒤섞인다. 먼저 업무 담당자에게 실제 사건을 묻는다.

고객이 주문을 확정하면 어떤 일이 일어나는가? 재고를 언제 예약하고, 품절이면 누가 대체 상품을 결정하는가?
배송 시간대를 선택할 때 차량 용량과 지역별 마감 시간을 누가 관리하는가?
취소가 발생하면 결제와 재고를 어느 순서로 복구하는가?

답을 통해 주문, 재고, 배송 배정, 결제 정산, 고객 지원 같은 후보를 만든다. 이름만으로 경계를 확정하지 말고, 업무 규칙·변경 이유·담당자의 용어가 함께 움직이는지 살펴본다. 예를 들어 배송 배정이 주문 상태와 다른 주기로 변경되고 독자적인 최적화 규칙을 가진다면 별도 하위 도메인으로 분석할 근거가 있다.

핵심·일반·지원 하위 도메인

세 유형은 기술 난이도만으로 구분하지 않는다. 현재 사업 전략에서 차별화에 얼마나 기여하는가가 판단의 중심이다.

유형	식료품 판매의 예시	설계·투자 판단
핵심(Core)	신선도와 차량 용량을 고려한 당일 배송 배정이 경쟁력인 경우	도메인 전문가와 함께 규칙을 모델링하고 실험에 투자
일반(Generic)	표준 인증, 범용 결제 연동	검증된 제품·서비스 도입을 먼저 검토
지원(Supporting)	내부 운영자의 교대 근무 입력 화면	필요한 규칙을 충족하는 단순한 구현을 선택

이 분류는 회사마다 다르며 시간이 지나면 바뀐다. 결제 경험 자체가 경쟁력인 회사에서는 결제가 핵심일 수 있다. 인증도 업계 규제와 특수한 신원 확인이 제품의 핵심이라면 범용 기능으로 취급하기 어렵다. 반대로 알고리즘이 복잡해도 사업 차별화에 기여하지 않으면 일반 하위 도메인일 수 있다.

지원 영역이 중요하지 않다는 뜻도 아니다. 교대 근무 화면의 오류가 배송을 멈출 수 있다. 중요도와 차별화는 다른 축이다. 따라서 모든 영역에 정확성·보안 기준을 적용하되, 차별화를 만드는 부분에 맞춤형 모델링과 실험 비용을 집중한다.

분류가 설계 선택에 미치는 영향

핵심인 배송 배정에서는 ‘배송 가능’이 단순한 불리언이 아닐 수 있다. 주문 마감 시각, 냉장 차량 용량, 주소 권역, 고객이 선택한 시간대가 함께 결정을 만든다. 이 규칙을 외부 솔루션의 고정된 필드에 억지로 넣으면 새 정책을 실험하기 어렵다. 반면 표준 인증 기능을 직접 만들면 본업과 관련 없는 보안 유지 비용이 늘 수 있다.

지원 영역은 CRUD로 시작할 수 있지만, 그 안에 복잡한 승인 규칙이 발견되면 다시 분류해야 한다. ETL은 Extract, Transform, Load(추출·변환·적재)의 약어이며, 단순 데이터 입력과 같지 않다. ETL도 데이터 품질 규칙이 사업 가치를 좌우한다면 별도로 분석할 필요가 있다.

하위 도메인과 바운디드 컨텍스트를 구별하기

하위 도메인은 사업 문제의 영역이고, 바운디드 컨텍스트는 특정 도메인 모델과 언어가 유효한 소프트웨어 경계다. 두 개가 항상 1:1로 대응하지는 않는다. 예를 들어 작은 팀은 재고와 주문을 한 시스템에서 운영하되 모듈 경계로 구별할 수 있다. 반대로 하나의 큰 결제 하위 도메인을 정산과 사기 탐지처럼 서로 다른 모델을 쓰는 여러 컨텍스트로 나눌 수 있다. 마이크로서비스 수를 먼저 정하고 하위 도메인을 끼워 맞추면 업무 경계를 놓치기 쉽다.

경계를 검토할 때는 유스케이스를 따라가 본다. 주문 확정 → 재고 예약 → 배송 시간 배정에서 각 단계의 입력·출력, 실패 시 책임자, 즉시 일치해야 하는 데이터를 적는다. 재고 예약 실패는 주문 확정 전에 반드시 알려야 하는지, 배송 배정은 뒤늦게 바뀌어도 되는지에 따라 계약과 통합 방식이 달라진다. 이 질문에 답하지 못한 상태에서 패키지나 데이터베이스를 분리하면 경계만 늘고 업무 규칙은 여전히 섞인다.

처음 분류는 가설이다. 새 상품 출시, 경쟁사 변화, 운영 사고가 생기면 하위 도메인의 가치와 경계를 다시 검토한다. 설계의 목적은 한 번 정한 지도를 고정하는 것이 아니라, 중요한 업무 규칙이 어디에 있는지 팀이 계속 같은 그림을 보게 하는 것이다.

참고: Martin Fowler, Bounded Context