MSA 기반으로 프로젝트 구현하는 와중에 DDD를 MSA랑 결합시키면 좋다는 말을 들었습니다. 그래서 팀원분들과 DDD를 공부하여 적용해보기로 하였습니다. DDD를 이해한다는 것이 생각 이상으로 쉽지 않았지만 최대한 정리해보고 제가 놓친 부분이 있다면 추후에 내용을 보충해 나갈 예정입니다.
✅DDD 등장 배경
소프트웨어를 설계할 때 고객의 요구사항을 정확히 이해하는 것이 매우 중요합니다. 과거에 기술 중심의 개발 방법론이 사용되었을 때는 기술적 요구사항을 중점적으로 다루고 비즈니스 측면에서 발생하는 다양한 요구사항을 효과적으로 반영하기에는 한계가 있었습니다. 비즈니스 전문가와 개발자 간의 소통이 원활하지 않으면, 최종 소프트웨어가 비즈니스의 실제 요구를 충족시키지 못할 수 있었습니다. 이러한 문제점들을 해결하기 위해 나온 설계가 도메인 주도 설계입니다.
즉, 소프트웨어와 실제 비즈니스 요구사항의 간극을 줄이기 위해 등장하였습니다.
✅DDD 핵심 가치
소프트웨어 개발에서 도메인 지식이 가장 중요한 요소임을 인식하고, 이를 중심으로 소프트웨어 설계합니다.
- 도메인 전문가, 이해 관계자 그리고 개발자가 동일한 지식을 공유하고 직접 소통하여 비즈니스와 기술 간의 간극을 좁히고 복잡한 시스템에서 발생할 수 있는 문제를 효과적으로 해결하는 것에 목적을 두고 있습니다.
✅간극 줄이는 방법
✔️ 유비쿼터스 언어 (도메인과 밀접하고 명확하게 표현된 용어)
// 도메인 생각하지 않고 작성한 코드
public enum OrderState {
STEP1, STEP2, STEP3, STEP4
}
// 도메인을 고려해서 작성한 코드
public enum OrderState {
WAITING_PAYMENT, PREPARE_PRODUCT, DELIVERY, SUCCESS
}
- 코드를 작성할 때 도메인에서 사용하는 용어는 매우 중요
- 도메인에서 사용하는 용어를 코드에 반영하지 않으면 개발자가 코드의 의미를 해석해야 하는 부담 존재
- DDD 저자 에릭 에반스는 언어의 중요성 강조하며 "유비쿼터스 언어" 라는 용어 사용
- 유비쿼터스 언어 : 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들어, 대화 문서, 도메인 모델, 코드 ,테스트 등 모든 곳에서 동일하게 사용하는 것
✔️ 도메인 모델
도메인 주도 설계에서 핵심 "개념"을 표현하는 방법
- 특정 문제 영역(도메인)에 대한 지식, 규칙, 그리고 로직을 추상화하여 개념적으로 표현
- 도메인 모델을 만들기 위해서는 핵심 구성 요소, 규칙, 기능을 파악해야 함
✅ DDD 구조와 용어들
✔️ 엔티티
고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 가짐
- 주문, 회원, 상품 등과 같이 도메인의 고유한 개념 표현
- 엔티티는 단순히 데이터를 담고 있는 데이터 구조라기 보단, 데이터와 함께 기능을 제공하는 객체
- 도메인 관점에서 기능을 구현하고 기능 구현을 캡슐화해서 데이터가 임의로 변경되는 것을 막을 수 있음
✔️ 밸류
고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나의 값을 표현할 때 사용
- 배송지 주소를 표현하기 위한 주소 (Address), 구매 금액을 위한 금액 (Money) 등
- 엔티티의 속성으로 사용할 뿐만 아니라 다른 Value 타입의 속성으로도 사용할 수 있음
✔️ 도메인 서비스
특정 엔티티에 속하지 않는 도메인 로직
- 예를 들어 할인 금액 계산은 상품, 쿠폰, 회원 등급 등 다양한 조건을 고려하여 이루어짐
- 이 로직의 주체가 명확하지 않을 때가 존재
- 이처럼 여러 엔티티와 값이 필요한 도메인 로직은 도메인 서비스에서 구현 가능
✔️ 애그리거트
관련된 객체들을 모아 하나의 단위로 취급하는 개념
- 연관 도메인을 애그리거트로 묶어 하나의 군집으로 이해한다면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악 가능 → 일종의 추상화?
- 애그리거트 전체를 관리할 주체가 필요 → 루트 엔티티
- 애그리거트는 반드시 하나의 루트 엔티티가 있고, 여러 개의 엔티티와 밸류 객체들이 포함될 수 있다.
✔️ Layered Architecutre
표현, 응용, 도메인 ,인프라스트럭쳐 총 4개의 계층으로 이루어져 있음
- 고수준 모듈이 저수준 모듈에 의존하지 않는 구조로 개발 필요
회고
사실, 아직도 DDD에 대한 개념을 완전히 이해하진 못했습니다. 하지만 2차 프로젝트를 진행하고 DDD 관점으로 고민하는 연습을 하며 개념에 대한 이해를 키워나갈 예정입니다.
'스파르타 > TIL' 카테고리의 다른 글
2024.09.13 | @PreAuthorize의 hasRole("") vs hasAuthority("") (0) | 2024.09.14 |
---|---|
2024.09.11 | MySQL 그리고 스키마(schema) (0) | 2024.09.11 |
2024.09.06 | record를 이용한 DTO 그리고 불변 객체 (3) | 2024.09.07 |
2024.09.05 | 재귀적 관계 모델링 ( or 계층적 데이터 모델링) (0) | 2024.09.06 |
2024.09.05 | 페이징 처리 (1) | 2024.09.05 |