[용어] 도메인(domain)이란 무엇인가?

개발 관련 업무를 하다보면 도메인이라는 용어가 자주 등장한다.
심지어 소스 코드 수준에서도 domain 이라는 패키지 혹은 디렉터리를 보았다.

 

도메인이라는 용어를 찾아 올라가면 2003년에 Eric Evans가 출판한 도메인 주도 설계을 만날 수 있다.

원서명: Domain-Driven Design: Tackling Complexity in the Heart of Software

 

위키북스에서 이대엽 님이 옮긴 한글판으로 읽었는데 나만 아니라 주변 사람들도 어렵거나 도중에 포기한 사람들을 발견했다.

사전적 정의

domain을 사전에서 찾아보면 영역, 범위 등으로 표현한다.

하지만 이런 우리말로는 그래서 '도메인이라는 것이 도대체 무엇인데?'라는 의문만 남긴다.

 

그래서 나는 이해를 돕기 위해 앞에 문제를 의미하는 problem 을 붙여서 problem domain (문제 영역) 이라고 부른다.

즉, '어떠한 문제를 해결하기 위한 영역'로 해석할 수 있는 것이다.

 

문제를 붙이는 것이 어색하지 않은 이유는 소프트웨어의 존재 이유 때문이다.

바로 현실에 있는 어떠한 문제를 해결 혹은 도움을 주기 위해 있는 것이다.

물경력과 문제 해결 능력

어제 퇴근을 하다가 요즘IT의 개발자의 물경력은 어떻게 만들어지는가 라는 글을 읽었다.

이 글을 요약하면 개발자에게 기술은 중요하지만 문제를 해결하는 능력이 진정한 성장이고 안티 물경력의 필수 요소라고 이야기합니다.

 

다시 도메인 주도 설계를 풀어 설명을 해보면, "문제 영역 자체에 관심을 가지고, 무엇을 위해 만들고 있는지 끊임 없이 생각"하는 것이라고 할 수 있을 것이다.

도메인이 왕이다.

Tom Hombergs의 만들면서 배우는 클린 아키텍처(원서명: Get Your Hands Dirty on Clean Architecture)의 마지막 장인 12장에는 "도메인이 왕이다"라는 부분이 있다.

도메인을 중심에 두는 스타일인 헥사고날 아키텍처에서는 도메인과 관련한 코드가 의존 관계에서 제일 가운데에 있다.

따라서 도메인 코드를 애플리케이션에 가장 중요한 요소로 볼지 여부가 프로젝트 아키텍처를 동인(움직일 요인; drive)이 된다.

Spring Boot 레퍼런스 문서의 전형적인 레이아웃(typical layout)

Spring Boot 1.0.0부터 1.5.22까지 레퍼런스의 레이아웃 예시가 아래와 같았다.

com
 +- example
     +- myproject
         +- Application.java
         |
         +- domain
         |   +- Customer.java
         |   +- CustomerRepository.java
         |
         +- service
         |   +- CustomerService.java
         |
         +- web
             +- CustomerController.java

domain 이란 패키지가 있었지만, service, web 이라는 기능 중심의 패키지 아래 나뉘어 있었던 것이다.

 

하지만 Spring Boot 2.0 부터 전형적인 레이아웃(typical layout) 이 아래와 같이 바뀌었다.

com
 +- example
     +- myapplication
         +- Application.java
         |
         +- customer
         |   +- Customer.java
         |   +- CustomerController.java
         |   +- CustomerService.java
         |   +- CustomerRepository.java
         |
         +- order
             +- Order.java
             +- OrderController.java
             +- OrderService.java
             +- OrderRepository.java

 

즉 service, controller 등의 역할 중심이 아닌, customer, order 등의 도메인 중심으로 패키지가 나뉘어 진 것이다.

 

당신의 선택은?

여러분은 도메인을 중심으로 둘 것인가? 기능 혹은 기술 중심으로 둘 것인가?
무엇이 되었던 결정을 해야 할 것이다.

from: https :ll