[도메인 주도 개발하기] 1장 – 1.1 도메인이란?

 

공부한 책: 도메인 주도 개발하기 – 최범균

1. 도메인(domain)이란?

도메인은 한 줄로 말하면,

소프트웨어가 해결하려는 문제 영역

 

책에서 드는 예시는 온라인 서점이다.

온라인 서점 소프트웨어는

• 상품 조회
• 구매
• 결제
• 배송 추적

같은 기능을 제공해야 한다.

이때 “온라인 서점”이라는 비즈니스 자체가 바로 도메인이다.

여기서 중요한 포인트는:

• 도메인은 기술(Java, Spring, JPA…) 이 아니라 업무/비즈니스의 세계를 가리킨다는 것.

---

2. 도메인은 여러 하위 도메인으로 나뉜다

하나의 도메인은 보통 너무 크기 때문에, 다시 하위 도메인(subdomain) 으로 쪼개서 본다.

"온라인 서점"이 상위 도메인라면 하위 도메인은 이런 식으로 나눌 수 있다.

• 주문(Order)
• 혜택(Benefit) – 쿠폰, 포인트, 할인 등
• 회원(Member)
• 결제(Payment)
• 카탈로그(Catalog) – 상품 목록, 상세
• 정산(Settlement)
• 배송(Delivery)

각 하위 도메인의 역할은 대략 이렇게 볼 수 있다.

• 카탈로그: 고객이 볼 수 있는 상품 목록/상세 제공
• 주문: 장바구니, 주문 생성, 주문 상태 변경(완료, 취소 등)
• 혜택: 쿠폰, 포인트, 특별 할인 정책
• 결제: 카드/계좌/간편결제 등 실제 금전 거래
• 배송: 출고, 송장, 배송 상태 추적
• 정산: 가맹점/공급사/출판사에게 돈을 어떻게 나눌지 계산

실제로 고객이 상품을 하나 구매하면,

주문 → 결제 → 배송 → 혜택 → 정산

이런 여러 하위 도메인의 기능이 한 번에 엮여서 동작한다.

---

3. 도메인의 모든 기능을 직접 구현하지는 않는다

중요한 사실은 "특정 도메인을 위한 소프트웨어라고 해서

그 도메인의 모든 기능을 우리가 직접 구현하는 것은 아니다" 라는것이다.

 

예를 들어 온라인 쇼핑몰을 생각해보면,

배송 도메인

많은 쇼핑몰이 택배사의 배송 시스템 전체를 직접 구현하는 대신, 외부 배송 업체(CJ, 로젠, 한진 등)의 시스템을 사용하고,

우리 쪽에서는 아래의 몇가지 정도만 구현한다.

• 송장 번호 관리
• 배송 상태 조회 API 연동
• 고객에게 보여줄 배송 추적 화면

즉, “배송 도메인” 전체를 다 만드는 게 아니라,
내가 직접 구현해야 할 부분 + 외부 시스템에 맡길 부분을 나눠서 가져간다.

결제 도메인

결제도 비슷도 배송도메인과 비슷하게 카드사/은행 프로토콜을 직접 구현하기보다는

보통은 PG사(결제 대행 업체)를 이용하여 연동하고

우리 쪽에서는 아래의 몇가지 정도만 구현한다.

• 결제 요청/응답 처리
• 결제 결과 저장
• 주문 상태 변경

결론적으로는 “이 도메인을 다룬다”는 말이 곧
“이 도메인의 모든 기능을 내가 코딩한다”는 뜻은 아니다! 

---

4. 하위 도메인의 구성은 비즈니스마다 다르다

도메인마다 “꼭 있어야 하는 하위 도메인 목록”이 정해져 있는 것은 아니다.

예를 들어:

• 모든 쇼핑몰이 고객 혜택(쿠폰, 포인트) 을 제공하는 것은 아니다.
• 규모가 작은 쇼핑몰은 정산 시스템을 따로 만들지 않고 엑셀로 수작업 정산을 할 수도 있다.
• 어떤 곳은 리뷰 기능이 아예 없을 수도 있다.

하위 도메인의 구성은 “우리 비즈니스가 실제로 무엇을 하느냐”에 따라 달라진다.

예시 1: B2B 대형 장비 판매 회사

• 주 고객: 기업
• 필요한 기능:
  • 온라인 카탈로그
  • 견적/주문서 접수

이런 경우:

• 온라인 결제, 배송 추적 같은 기능은 굳이 웹 시스템에서 제공할 필요가 없을 수도 있다.

예시 2: 일반 소비자 대상 의류/액세서리 쇼핑몰

• 주 고객: 일반 개인
• 필요한 기능:
  • 카탈로그
  • 리뷰
  • 장바구니/주문
  • 결제
  • 배송
  • 회원/마이페이지
  • (필요하다면 혜택/정산 등)

이렇게 같은 “온라인 판매” 도메인이라도
어떤 하위 도메인을 도입할지는 회사/비즈니스 전략에 따라 천차만별이다.

---

5. 내 프로젝트에 대입해 본 도메인/하위 도메인

내가 하고 있는 프로젝트는 간단히 말하면, 학교 실내 공기질 & ERV 장비 관리/모니터링 시스템 이 있다.

ERD를 기준으로 이 시스템의 하위 도메인을 정리해보면 아래와 같다.

1. 시설/위치 도메인
   • school : 학교 정보, 주소, 위치
   • air_station  : 공기질 측정소 등
2. 사용자 도메인
   • user : 로그인 계정, 권한, 소속 학교 등
3. 장비(PC ERV) 관리 도메인
   • pc_erv_device : 장비 정보
   • pc_erv_device_grade_class_mapping: 각 학교/교실에 설치된 장비의 매핑 정보
4. 장비 상태/모니터링 도메인
   • control_status : 전원, 풍량, 자동/수동, 에러, 필터 교체 여부 등
   • sensor_status : CO₂, 미세먼지, 온도, 습도, 라돈, TVOC 등
5. 유지보수/이력 도메인
   • repair_history : 수리 이력
   • filter_history : 필터 교체 이력

또한, 이 시스템에서도 책에서 말한 것처럼 “모든 걸 직접 구현하지 않는 영역”이 존재한다.

• 알림(SMS, 푸시 등) → 외부 알림 서비스 연동
• 인증/로그인 → 향후에는 외부 인증(SSO, 공공 인증 등)을 도입할 수도 있음
• IoT 장비 통신 → 별도의 게이트웨이/브로커에서 처리,
  이 시스템은 상태 정보만 받아 저장/조회

이렇게 보면, 책에서 나온 “온라인 서점 도메인”의 구조가 내 프로젝트에도 거의 적용되는것같다..

도메인 기반으로 얼추 프로젝트를 만들었다는 사실 ㅜㅜ

---

6. 오늘 정리하며 느낀 점

1. 도메인 = 기술이 아니라 문제 영역
   • 지금까지는 “도메인 객체” 라고 하면 그냥 domain 패키지 아래 있는 엔티티 정도로만 생각했는데,
     이 시스템의 목적을 이루는 기능 등을 모은게 도메인인것같다 
2. 하위 도메인은 ‘정해진 답’이 없다
3. 외부 시스템에 맡길 영역을 분리해서 보는 눈이 필요하다
   • 배송/결제처럼, 우리 도메인 안에 있지만 “내가 직접 구현하지 않는 부분”을 명확히 구분하면
     책임이 더 분명해지고 설계도 덜 복잡해질 것 같다!!

---

마무리

1.1에서는

“도메인이 무엇인지, 그리고 그 안을 어떻게 하위 도메인으로 나눌 것인지”

에 대한 감을 잡는 챕터였다!