DDD START SERIES는 도메인 주도 개발 시작하기 책을 참고 하여 작성된 요약 글 입니다.

EP.1.1 도메인 이란?

예를 들어 개발자 입장에서 온라인 서점은 구현해야 할 소프트웨어의 대상이 될 수 있다.

온라인 서점을 온라인으로 책을 판매하는 데 필요한 상품 조회, 구매, 결제, 배송 추적 등 기능이 필요하다.

이때 온라인 서점은 소프트웨어로 해결하고자 하는 문제 영역, 즉 도메인에 해당한다.

한 도메인은 다시 하위 도메인으로 나눌 수 있다.

Example

        ---- [정산]
       /
      /
[주문] ------ [회원]
      \       |
       \      |
        ---- [회원]

무조건 고정된 하위 도메인이 존재하는 것은 아니고 필요에 따라 나뉠 수 있다. (있을 수도 있고 없을 수도 있다.)

EP.1.2 도메인 전문가와 개발자 간 지식 공유

첫 단추가 잘못 끼워지면 모든 단추가 잘못 끼워지듯이 요구사항을 올바르게 이해하지 못하면 요구하지 않은 엉뚱한 기능을 만들게 된다.

잘못 개발한 코드를 수정하기 위해서는 많은 노력이 든다. 그러므로 요구사항을 올바르게 이해 해야한다.

그렇기 때문에 도메인 전문가 만큼은 아니지만 이해관계자와 개발자도 도메인 지식을 갖춰야 한다.

제품 개발과 관련된 도메인 전문가, 관계자, 개발자가 같은 지식을 공유하고 직접 소통할수록 도메인 전문가가 원하는 제품을 만들 가능성이 높아진다.

도메인 주도 설계에서 도메인 전문가는 그만큼 중요하다.

Garbage in, Garbage out을 기억 하라.

EP.1.3 도메인 모델

도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는 데 도움이 된다.

도메인을 이해하려면 도메인이 제공하는 기능과 도메인의 주요 데이터 구성을 파악해야 하는데 이런 면에서 기능과 데이터를 함께 보여주는 객체 모델은 도메인을 모델링하기에 적합하다.

도메인 모델을 객체로만 모델링할 수 있는 것은 아니다.

관계가 중요한 도메인이라면 그래프를 이용해서 도메인을 모델링할 수 있다.

수학 공식을 활용해서 도메인 모델을 만들 수도 있다. 도메인을 이해하는 데 도움이 된다면 표현 방식이 무엇인지는 중요하지 않다.

도메인 모델은 기본적으로 도메인 자체를 이해하기 위한 개념 모델이다.

개념 모델과 구현 모델은 서로 다른 것이지만 구현 모델이 개념 모델을 최대한 따르도록 할 수는 있다.

EP.1.4 도메인 모델 패턴

z

아기텍처 구성 (원본)

도메인 모델 패턴은 아키텍처 구성의 도메인 계층을 객체 지향 기법으로 구현하는 패턴을 말한다.

도메인 계층은 도메인의 핵심 규칙을 구현한다. 주문 도메인의 경우 ‘출고 전에 배송지를 변경할 수 있다’ 라는 규칙과 ‘주문 취소는 배송 전에만 할 수 있다’라는 규칙을 구현한 코드가 도메인 계층에 위치하게 된다.

이런 도메인 규칙을 객체 지향 기법으로 구현하는 패턴이 도메인 모델 패턴이다.

EP.1.5 도메인 모델 도출

아무리 뛰어난 개발자라 할지라도 도메인에 대한 이해 없이 코딩을 시작할 수는 없다.

기획서, 유스케이스, 사용자 스토리와 같은 요구사항과 관련자와의 대화를 통해 도메인을 이해하고 이를 바탕으로 도메인 모델 초안을 만들어야 비로소 코드를 작성할 수 있다.

그리고 나서 만든 모델은 요구사항 정련을 위해 도메인 전문가나 다른 개발자와의 논의하는 과정에서 공유하기도 한다.

EP.1.6 엔티티와 벨류

요구사항에서 도출한 모델은 크게 엔티티와 벨류로 구분할 수 있다.

엔티티와 벨류를 제대로 구분해야 도메인을 올바르게 설계하고 구현할 수 있기 때문에 이 둘의 차이를 명확하게 이해하는 것은 도메인을 구현하는 데 있어 중요하다.

1.6.1 엔티티

엔티팅의 가장큰 특징은 식별자를 가지는 것이다.

식별자는 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다. 예를 들어 주문 도메인에서 각 주문은 주문번호를 가지고 있는데 이 주문번호는 각 주문마다 서로 다르다. 따라서 주문번호가 주문의 식별자가 된다.

주문에서 배송지 주소가 바뀌거나 상태가 뷔꾸더라도 주문번호가 바뀌지 않는 것처럼 엔티티의 식별자는 바뀌지 않는다. 엔티티를 생성하고 속성을 바꾸고 삭제할 때까지 식별자는 유지된다.

1.6.2 엔티티의 식별자 생성

엔티티의 식별자를 생성하는 시점은 도메인의 특징과 사용하는 기술에 따라 달라진다.

  • 특정 규칙에 따라 생성
  • UUID나 Nano ID와 같은 고유 식별자 생성기 사용
  • 값을 직접입력
  • 일련번호 사용(시퀀스나 DB의 자동 증가 컬럼 사용)

1.6.3 벨류 타입

벨류 타입은 개념적으로 완전한 하나를 표현할 떄 사용한다.

벨류 객체의 데이터를 변경할 때는 기존 데이터를 변경하기보다는 변경한 데이터를 갖고 새로운 밸류 객체를 생성하는 방식을 선호한다. (불변 객체는 참조 투명성과 스레드에 안전한 특징을 가지고 있다.)

벨류 타입을 분현으로 구현하는 여러 이유가 있는데 가장 중요한 이유는 안전한 코드를 작성할 수 있는다는 데 있다.

1.6.4 엔티티 식별자와 밸류 타입

도메인에서 특별한 의미를 지니는 경우가 많기 때문에 식별자를 위한 벨류 타입을 사용해서 의미가 잘 드러날 수 있도록 하자.

1.6.5 도메인 모델에 set 메서드 넣지 않기

접근 범위를 private으로 선언한 경우 외부에서 데이터를 변경할 목적으로 set 메서드를 사용할 수 없다.

불변 벨류 타입을 사용하면 자연스럽게 벨류 타입에는 set 메서드를 구현하지 않는다.

set 메서드를 구현해야 할 특별한 이유가 없다면 불변 타입의 장점을 살릴 수 있도록 벨류 타입은 불변으로 구현한다.

EP.1-7 도메인 용어와 유비쿼터스 언어

코드를 작성할 때 도메인에서 사용하는 용어는 매우 중요하다.

도메인에서 사용하는 용어를 코드에 반영하지 않으면 그 코드는 개발자에게 코드의 의미를 해석해야 하는 부담을 준다.

코드를 도메인 용어로 해석하거나 도메인 용어를 코드로 해석하는 과정이 줄어든다.

이는 코드의 가독성을 높이고 코드를 분석하느고 이해하는 시간을 줄여준다.

최대한 도메인 용어를 사용해서 도메인 규칙을 코드로 작성하게 되므로 버그또한 줄어 들게 된다.

도메인 용어에 알맞은 단어를 찾는 시간을 아까워하지 말자.

REFERENCE

itssobeauti 도메인 주도 개발 시작하기

itssobeauti