[도메인 주도 설계] 도메인이란? (도메인과 친해져보자)

도메인이란 무엇을 뜻할까?

도메인을 한 줄로 정의하자면 소프트웨어로 해결하고자 하는 문제 영역을 뜻한다.
만약, 우리가 온라인 서점이라는 서비스를 제공한다면 온라인 서점은 도메인(domain)이 될 수 있다.
그리고 도메인은 여러 하위 도메인으로 구성된다.

온라인 서점 (도메인)

• 주문 (하위 도메인)
• 정산 (하위 도메인)
• 배송 (하위 도메인)
• 결제 (하위 도메인)

고객이 책을 주문하고 결제하면 책이 배송된다.
이렇게 하위 도메인은 다른 도메인이랑 엮이면서 완전한 기능을 제공하게 된다.

도메인 모델?

다양한 정의가 존재하는데 아래 내용만 짚고 넘어가자

• 특정 도메인을 개념적으로 표현한 것
  • 도메인이 제공하는 기능(메소드)와 주요 데이터(프로퍼티)를 가지고 있는 모델
• 도메인 계층을 구현할 때 사용하는 객체 모델을 언급할 때도 도메인 모델이란 용어를 사용한다.

도메인 모델이란 단순히 Service Layer의 메소드 로직을 실행시킬 때 필요한 데이터 집합이 아닌가? (궁시렁 궁시렁..)
사실 내입장에서 도메인 모델은 상당히 낯설다. 용어가 낯설기 보다는 풍부한 기능을 갖고 있는 도메인 객체를 만들어 본적이 많이 없기에..

아키텍처 구성은 어떻게 하는게 좋을까?

아마 일반적으로는 표현(presentation)-응용(Service or business)-dao(dao or persistence or repository) 이렇게 3가지 layer로 사용하겠지만(아니면 죄송..) 도메인 모델에 힘을 실어주기 위하여 4개의 layer로 구성해서 사용해본다.

• Presentation : 사용자의 요청을 처리하고 응답을 제공
• Application : 사용자가 요청한 기능을 실행. 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행
• Domain : 시스템이 제공할 도메인 규칙을 표현
• Infrastructure : 데이터베이스나 메시징 시스템 같은 외부 연동 처리

도출한 모델은 크게 엔티티와 밸류로 구분된다.

엔티티

• 식별자를 가지는 객체
  • 특정 규칙에 따라 생성
  • UUID 혹은 고유 식별자 생성기 사용
  • 일려 번호 사용(시퀀스 or DB 자동 증가)
• 주문(Order)가 엔티티가 되며 주문번호를 속성으로 갖는다.

밸류 타입

• 개념적으로 완전한 하나를 푠현할 때 사용(ShippingInfo, Address ..)
• 밸류 객체의 데이터를 변경할 때는 기존 데이터를 변경하기 보다는 변경한 데이터를 갖는 새로운 밸류 객체를 생성하는 방식을 선호 (copy, 불변)

도메인 모델에 set 메서드를 넣지 말자

• 불완전한 상태로 사용되는 것을 막으려면 생성 시점에 필요한 것을 전달해줘야 함

// 권장하지 않음 (X)
val order = Order()
order.setOrderLine(lines)
order.setShippingInfo(shippingInfo)

// 주문자(Orderer)를 설정하지 않은 상태에서 주문 완료 처리
order.setState(OrderState.PREPARING)


// 권장함 (O)
val order = Order(orderer, lines, shippingInfo, OrderState.PREPARING)

• orderer가 null인 상태에서 주문 상태를 변경할 수 없음. 그렇다면 orderer가 정상인지 확인해 null 체크하는 로직을 setState() 메서드에 위치시키는 것도 맞지 않음 -> 생성자로 받자

유비쿼터스 언어(ubiquitous language)를 사용하자.

• 전문가, 관계자, 개발자가 도메인 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어를 사용한다.
  • 개발자만 혹은 도메인 전문가만 아는 언어는 사용 금지
  • 코드에는 STEP1, STEP2 로 처리한다고 개발자만 아는 코드값으로 얘기하지 말자는 얘기다. 애초에 설계를 그렇게 가져가면 안된다.
• 소통 과정에서 발생하는 용어의 모호함을 줄일 수 있고 개발자는 도메인과 코드 사이에서 불필요한 해석 과정을 줄일 수 있다.

---

도메인 주도 설계는 객체지향이라는 패러다임의 Best Practice 이다. 따라서 무조건적으로 따를 필요는 없다. 경험을 해보고 취할 이득이 많다고 생각하면 사용하자.
++)

• 도메인 모델 만들 때, 처음부터 완벽한 개념 모델을 만들기보다는 전반적인 개요를 알 수 있는 수준으로 개념 모델을 작성하자. (관련 경험과 통찰력을 얻게 되면 완전히 다른 의미로 해석되는 케이스가 있기 때문에, 결국 도메인 모델은 변경되거나 보완될 가능성이 많다.)
• 문서화는 왜 해야하는 것일까?
  • 지식을 공유하기 위함
  • 실제 구현 코드로 내용을 파악할 수 있으나, 상세한 내용을 다루기 때문에 전체 소프트웨어를 분석하려면 많은 시간을 투자해야 한다.
  • 전반적인 기능 목록이나 모듈 구조는 상위 수준에서 정리한 문서를 참조하는 것이 소프트웨어 전반을 이해하는데 도움이 된다.