1. 도메인 모델 시작하기

도메인 주도개발 책 공부를 하면서 내용 정리

 

 

1.1 도메인이란?

도메인이란?

위키 백과

SI회사에 다닐 때 개발스킬이 아니라 업무에 대한 지식을 얘기할 때 도메인 지식이라는 말을 사용했던 것같은데

쉽게 설명하자면 "소프트웨어 프로그램에 대한 기능적으로 구분한 영역? 단위?"이라고 할 수 있을거 같다.

 

 

 

책에서는 온라인 서점을 예시로 보여준다.

한 도메인은 다시 하위 도메인으로 나눌 수 있다. 사진에서와 같이 온라인 서점 도메인은 몇 개의 하위 도메인으로 나눌 수 있다.

한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공한다.

 

 

하지만 특정 도메인을 위한 소프트웨어라고 해서 도메인이 제공해야 할 모든 기능을 직접 구현하는 것은 아니다.

(ex: 배송시스템/결제 시스템 등은 외부 업체를 이용해서 처리할 때가 많음)

또한 도메인마다 고정된 하위 도메인이 존재하는 것은 아니다.(같은 업종이어도 고객 혜택을 제공하지 않을 수도 있고, 규모가 작으면 엑셀과 같은 도구를 이용해서 수작업으로 정산처리를 할 수도 있음)

하위 도메인을 어떻게 구성할지 여부는 상황에 따라 달라진다.(업종이 같더라도 B2C / B2B 차이와 같이 구성이 다를수있음)

 

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

개발자는 프로그램을 만들 때 요구사항을 분석하고 설계하여 코드를 작성하고 배포한다.

요구사항을 이해하지 못하면 요구하지 않은 엉뚱한 기능을 만들게 된다.

-> 작성한 코드는 쉽게 고치기 어렵다.(잘못 개발한 코드를 수정해서 올바르게 고치려면 많은 노력이 든다.)

->한 번 개발할 때 잘하자

 

-코딩에 앞서 요구사항을 올바르게 이해하는 것이 중요하다.

-간단한 방법 -> 개발자와 전문가가 직접 대화하는 것(개발자와 전문가 사이에 전달자가 많으면 정보가 왜곡되고 손실이 발생됨)

-도메인 전문가 만큼은 아니겠지만 이해관계자와 개발자도 도메인 지식을 갖춰야 한다.(같은 지식을 공유하고 직접 소통할수록 도메인 전문가가 원하는 제품을 만들 가능성이 높아짐)

 

1.3 도메인 모델

도메인 모델에는 다양한 정의가 존재 기본적으로 도메인 모델은 특정 도메인을 개념적으로 표현한 것

온라인 쇼핑몰 예시

 

객체를 이용한 도메인 모델

-기능과 데이터를 함께 보여주는 객체 모델은 도메인을 모델링하기에 적합하다.

 

상태 다이어그램을 이용한 도메인 모델

 

 

도메인 모델을 표현하는 방법은 상황에 따라 다양함

예시)

-관계가 중요한 도메인 -> 그래프를 이용해서 도메인을 모델링

 

도메인 모델 -> 도메인 자체를 이해하기 위한 개념 모델

객체 기반 모델 기반으로 도메인을 표현 -> 객체 지향 언어를 이용해서 구현 가능

수학적인 모델 기반으로 도메인을 표현  -> 함수를 이용해서 구현가능

 

여러 하위 도메인을 하나의 다이어그램에 모델링하면 안됨 WHY-> 도메인에 따라 용어 의미가 결정되기 때문 각 하위 도메인마다 별도로 모델을 만들어야함 WHY->모델의 각 구성요소는 특정 도메인으로 한정할 때 비로소 의미가 완전해짐

 

1.4 도메인 모델 패턴

 

애플리케이션의 아키텍처 4가지

 

아키텍처 구성

영역설명

사용자 인터페이스(UI) 또는 표현(Presentation)	사용자의 요청을 처리하고 사용자에게 정보를 보여준다. 사용자는 소프트웨어를 사용하는 사람과 외부 시스템
응용(Application)	사용자가 요청한 기능을 실행한다. 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다.
도메인	시스템이 제공할 도메인 규칙을 구현한다.
인프라스트럭처(Infrastructure)	데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동을 처리한다.

도메인 계층은 도메인의 핵심 규칙을 정의한다.

 

 

도메인 모델 패턴

-아키텍처 상의 도메인 계층을 객체 지향 기법으로 구현하는 패턴

 

예제 2가지 조건으로 코드(주문)

-출고 전에 배송지를 변경 할 수 있다.

-주문 취소는 배송 전에만 할 수 있다.

 

핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있게 된다.

 

개념 모델과 구현 모델 개념 모델 - 데이터베이스, 트랜잭션 처리, 성능, 구현 기술과 같은 것은 고려하고 있지 않아, 실제 코드를 작성할 때 개념 모델을 그대로 사용할 수 없음. 그래서 개념 모델 구현 가능한 형태의 모델로 전환하는 과정을 거친다. 프로젝트 초기에는 개요 수준의 개념 모델로 도메인에 대한 전체 윤곽을 이해하는데 집중하고, 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전시켜 나가야 한다.

 

1.5 도메인 모델 도축

구현을 시작하려면 도메인에 대한 초기 모델이 필요하다.

-모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것

 

책에서는

주문 도메인과 관련 된 요구사항을 차례로 코드에 녹여내서 도메인 모델을 점진적으로 만들어 나가는 것을 보여준다.

 

요구사항에 대해서 어떻게 코드로 구현하는지 예를 들기

p36

 

코드 자체도 문서화의 대상 -단순히 코드를 보기 좋게 작성하는 것뿐만 아니라 도메인 관점에서 코드가 도메인을 잘 표현해야 비로소 코드의 가독성이 높아지고 문서로서 코드가 의미를 갖는다.

1.6 엔티티와 벨류

도출한 모델은 엔티티 / 밸류 로 나눌 수 있다.

 

1.6.1 엔티티

엔티티의 가장 큰 특징

• 식별자를 갖는다.
• 식별자는 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다.
• 엔티티를 생성하고 속성을 바꾸고 삭제할 때까지 식별자는 유지된다.
• 두 엔티티 객체의 식별자가 같으면 두 엔티티는 같다고 판단할 수 있다.(equals() / hashCode() 메서드로 구현 가능)

 

1.6.2 엔티티의 식별자 생성

엔티티 식별자 생성 방식

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

날짜와 시간 이용시 주의 점

• 같은 시간에 동시에 식별자를 생성해도 같은 식별자가 만들어지면 안 된다.

회원 아이디 / 이메일 사용식 주의 점

• 사용자가 직접 입력하는 값이므로 중복 불가하도록 방지처리가 필요하다.

1.6.3 밸류 타입

• 밸류 타입은 개념적으로 완전한 하나를 표혈할 때 사용 한다.
  • 예시)
  • 주문에서 받는 사람을 위한 받는 사람의 정보와 주소가 모두 있는 ShippingInfo클래스
  • 밸류 타입으로 나누기
    • -->받는 사람 - Receiver(받는 사람)
    • -->주소 -  Address(주소)
    • 밸류 타입을 사용함으로써 개념적으로 완전한 하나를 잘 표현할 수 있다.
• 밸류 타입을 위한 기능을 추가할 수 있다.
• 밸류 객체의 데이터를 변경할 때는 기존 데이터를 변경하기보다는 변경한 데이터를 갖는 새로운 밸류 객체를 생성하는 방식을 선호한다.
  • 불변 객체
    • 참조 투명성과 관련된 문제(데이터 변경으로 인한) 방지
    • 스레드에 안전한 특징을 갖고있다.(수정이 불가하기때문에)

 

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

식별자를 위한 밸류 타입을 사용해서 의미가 잘 드러나도록 할 수 있다. (예: OrdNo)

 

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

• 도메인 모델에 get/set 메서드를 무조건 추가하는것을 좋지 않은 버릇이다.
• 특히 set메서드는 도메인의 핵심 개념이나 의도를 코드에서 사라지게 한다
• 도메인 객체가 불완전한 상태로 사용되는 것을 막으려면 생성 시점에 필요한 것을 전달해 주어야 한다.(생성자를 통해 필요한 데이터를 모두 받아야 한다.)

 

1.7 도메인 용어와 유비쿼터스 언어

• 도메인 용어를 사용하여 코드를 작성하게 되면 가독성을 높여서 코드를 분석하고 이해하는 시간을 줄여준다.
• 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들고 모든 곳에서 같은 용어를 사용한다.
  • 소통 과정에서 발생하는 용어의 모호함을 줄일 수 있다.
  • 개발자는 도메인과 코드 사이에서 불필요한 해석 과정을 줄일 수 있다.