교내 웹개발동아리 EFUB 내에서 진행된 DDD 스터디
기간: 2023.03.07 ~ 2023.05.08
도서: 도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지 (최범균)
1.1 도메인이란?
-
도메인(domain) : 소프트웨어로 해결하고자 하는 문제 영역
ex) 온라인 서점 -> 상품 조회, 구매, 결제, 배송 추적 등의 기능 제공, 개발자가 구현해야 할 소프트웨어의 대상 -
한 도메인은 다시 하위 도메인으로 나눌 수 있음
ex) 주문 = 회원+혜택+결제+배송+정상+(카탈로그+리뷰)
-
도메인이 제공해야 할 모든 기능을 직접 구현하는 것은 아님
ex) 자체적인 배송 시스템 X -> 외부 배송 업체 시스템 사용 및 일부 기능 연동
1.2 도메인 전문가와 개발자 간 지식 공유
-
전문가 : 해당 도메인에 대한 지식과 경험을 바탕으로 본인들이 원하는 기능 개발 요구
-
개발자 : 요구사항을 분석, 설계, 코드 작성, 테스트, 배포
-
코딩에 앞서 요구사항을 올바르게 이해하는 것이 가장 중요
-> 같은 지식을 공유하고 직접 소통"Garbage in, Garbage out"
개발자는 요구사항을 이해할 때 왜 이런 기능을 요구하는지 또는 실제로 원하는 게 무엇인지 생각하고 전문가와 대화를 통해 진짜 요구사항을 찾아야 함
1.3 도메인 모델
-
도메인 모델 : 특정 도메인을 개념적으로 표현한 것
-
객체 기반 도메인 모델 : 도메인이 제공하는 기능과 도메인의 주요 데이터 구성
-
상태 다이어그램
-
-
도메인 모델 표현 시 UML 표기법(클래스 다이어그램, 상태 다이어그램 등)만 사용해야 하는 것은 아님 -> 그래프, 수학 공식 등
-
도메인 모델은 기본적으로 도메인 자체를 이해하기 위한 개념 모델 -> 개념 모델을 최대한 따르는 구현 모델을 만들어야 함
ex) 객체 기반 도메인 모델 -> 객체 지향 언어를 이용하여 구현, 수학적인 모델 -> 함수 이용하여 구현
각 하위 도메인마다 별도로 모델을 만들어야 함
-> 각 하위 도메인이 다루는 영역은 서로 다르기 때문에 같은 용어라도 하위 도메인마다 의미가 달라질 수 있기 때문
ex) 카탈로그 도메인의 상품(상품 가격, 상세 내용)과 배송 도메인의 상품(고객에게 실제로 배송되는 물리적인 상품)
1.4 도메인 모델 패턴
| 영역 | 설명 |
|---|---|
| 사용자 인터페이스(UI) 또는 표현(Presentation) | 사용자의 요청을 처리하고 사용자에게 정보를 보여줌. 여기서 사용자는 소프트웨어를 사용하는 사람뿐만 아니라 외부 시스템일 수도 있음. |
| 응용(Application) | 사용자가 요청한 기능을 실행함. 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행함. |
| 도메인(Domain) | 시스템이 제공할 도메인 규칙을 구현함. |
| 인프라스트럭처(Infrastructure) | 데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동을 처리함. |
-
도메인 모델 : 아키텍처 상의 도메인 계층을 객체 지향 기법으로 구현하는 패턴, 도메인의 핵심 규칙을 구현
-
핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야 할 때 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있음
- 개념 모델 : 순수하게 문제를 분석한 결과물
-> 기능적인 부분을 고려하지 않기 때문에 이를 구현 가능한 형태의 모델로 전환하는 과정 필요- 처음부터 완벽한 개념 모델을 만들기보단 전반적인 개요를 알 수 있는 수준으로 작성해야 함
- 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전시켜야 함
1.5 도메인 모델 도출
-
도메인 모델링의 기본 작업 : 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것
-
ex) 주문과 관련된 요구사항으로부터
Other,OtherLine,ShippingInfo,OrderState등의 도메인 모델을 점진적으로 만들어 나가는 과정이 p.35~40에 상세하게 적혀있음
코드의 문서화
- 문서화는 지식을 공유하기 위한 수단
- 단순히 코드를 보게 좋게 작성하는 것이 아닌, 도메인 관점에서 코드가도메인을 잘 표현해야 가독성도 높아지고 문서호서 코드가 의미를 가짐
1.6 엔티티와 밸류
엔티티(Entity)와 밸류(Value)를 제대로 구분해야 올바른 도메일 설계 및 구현 가능
-> 둘의 차이를 명확하게 이해하는 것이 중요
1.6.1 엔티티
- 엔티티 객체마다 고유한 식별자를 가짐
ex) 주문번호: 주문의 식별자 - 식별자는 엔티티가 삭제될 때까지 바뀌지않고 유지됨
- 식별자가 같으면 두 엔티티는 같음
-> 식별자 이용해서equals()메서드와hashCode()메서드 구현 가능
1.6.2 엔티티의 식별자 생성
- 특정 규칙에 따라 생성
- 흔히
현재 시간 + 다른 값형태로 사용. 주의할 점은 동시에 생성되는 식별자도 다르게 생성되어야 함.
- 흔히
- UUID나 Nano ID와 같은 고유 식별자 생성기 사용
//java.util.UUID 클래스를 사용해서 UUID 생성 가능
UUID uuid = UUID.randomUUID();
String strUuid = uuid.toString();- 값을 직접 입력
- ex) 회원의 아이디나 이메일 -> 중복 입력하지 않도록 사전에 방지
- 일련번호 사용(시퀀스나 DB의 자동 증가 칼럼 사용)
- 주로 데이터베이스가 제공하는 자동 증가 기능 사용.
- 아니면 식별자 만들고 엔티티 객체 생성할 때 식벽자 전달하는 방법도 있음.
1.6.3 밸류 타입
p.46~52 예제코드 참고
- 밸루 타입은 개념적으로 완전한 하나를 표현할 때 사용
- 밸류 타입이 꼭 두 개 이상의 데이터를 가져야 하는 것은 아님. 의미를 명확하게 표현하기 위해 밸류 타입을 사용하는 경우도 있음
- 밸류 타입의 장점
- 코드를 이해하는데 도움이 됨
- 밸류 타입을 위한 기능을 추가할 수 있음
불변(immutable): 데이터 변경 기능을 제공하지 않는 타입
-> 안전한 코드 작성 가능
1.6.4 엔티티 식별자와 밸류 타입
- 엔티티 식별자의 실제 데이터는 String과 같은 문자열로 구성된 경우가 많음
- 도메인에서 특별한 의미를 지니는 경우, 단순한 문자열보다 식별자를 위한 밸류 타입을 사용해서 의미를 잘 드러낼 수 있음
public class Order {
public OrderNo id; // OrderNo 타입 자체로 id가 주문번호임을 알 수 있음.
...
public OrderNo getId() {
return id;
}
}1.6.5 도메인 모델에 set 메서드 넣지 않기
set메서드의 문제점- 단순히 필드값만 변경하고 끝나기 때문에 상태 변경과 관련된 도메인 지식이 코드에서 사라짐
- 도메인 객체를 생성할 때 온전하지 않은 상태가 될 수 있음 (필요한 값이 설정되지 않은 상태에서 다음 단계로 넘어갈 수 있음. 즉, 생성자를 통해 필요한 값을 설정하고 데이터가 올바른지 검사하는 복잡한 과정이 필요함)
- 불변 밸류 타입을 사용하면 set메서드 필요 없음
-> 불변 타입의 장점을 살릴 수 있도록 밸류 타입은 불변으로 구현
DTO(Data Transfer Object)의 get/set메서드
- 예전에는 DTO에 get/set 메서드 구현해서 사용
- 요즘에는 프레임워크가 제공하는 rivate 필드에 직접 값을 할당할 수 있는 기능을 활용 -> DTO도 불변 객체가 되어 불변의 장점을 DTO까지 확장 가능
1.7 도메인 용어와 유비쿼터스 언어
-
코드 작성 시 도메인에서 사용하는 용어는 매우 중요함
-
도메인에서 사용하는 용어를 코드에 반영하지 않으면 개발자가 코드의 의미 해석해야 하는 부담이 생김.
-
유비쿼터스 언어(ubiquitous language)
- 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어 사용
- 소통 과정에서 발생하는 용어의 모호함 줄이고, 개발자는 도메인과 코드 사이에서 불필요한 해석 과정 줄일 수 있음
- ex)
STEP1,STEP2대신PAYMENT_AITING,PREPARING등 사용
