728x90
반응형
DDD 란?
- 다른 블로그를 보다가 딱히 명확하게 정리 된게 없어서 정리를 해봅니다.
- 번역하면 Domain Driven Design 도메인 주도 개발이다.
- 도메인을 중심으로 설계해 나가는것을 의미한다.
DDD 나온이유
그럼 왜 DDD 설계가 필요할까?
탄생 배경을 보자.
- DDD 의 탄생배경은 다음과 같다.
- Eric Evans의 책 제목인 Domain Driven Design의 약자인 DDD였다.
- DDD 가 나온 이유는 설계자와 개발자 둘의 언어 장벽을 해결 한다
- 쉽게 말해서 개발자 설계자 모두 도메인 관점에서 문제를 바라보는 것이다.
DDD 의 주요 목적
- 도메인 모델과 도메인 로직에 집중한다.
- 유비쿼터스 랭귀지를 사용해 설계자와 개발자 사이의 소통을 원활하게 한다.
- 유비쿼터스 랭귀지를 사용하여 도메인과 구현을 만족하는 도메인 모델을 만든다.
- 즉 소프트웨어 엔티티와 도메인을 일치시킨다. - 비지니스를 도메인 별로 나눈다.
Ubiquitous Language
유비쿼터스 랭귀지를 사용해서 소통을 원할하게 한다고 했다.
그럼 정확이 뭐란것인가?
- 도메인에 사용하는 용어
- 보편적인 언어를 제공한다.
- 즉 둘다 이해할수 있는 용어를 만들거나 기존에 있던걸 사용한다.
- 예를들어 앞으로 배송은 Delivery 라고 정합니다.
- 즉 공통언어를 만드는것이다.
Domain 이란?
그럼 도메인을 위주로 개발한다는데 도메인이 무엇인가?
- 소트프웨어로 해결하고자 하는 문제영역
- 도서구매 사이트를 예를 들면 다음과 같은 도메인을 생각할수 있다.
- Order Domain: 도서구매사이트에서 주문을 하는 도메인
- Delivery Domain: 배송을 담당하는 도메인
- Member Domain: 회원을 관리하는 도메인
Domain 모델이란?
- 도메인을 개념적으로 표현한 것이다.
- 도서구매를 할때 필요한건 여러가지가 있지만 간단하게
- 주문서 모델, 제품모델, 배송모델 이 있겠다. - 모델을 표현하는 방법
- 클래스 다이어그램, 상태다이어그램 등등 표현을 하면 그것이 모델이다.
Domain 모델 요소
| 요소 | 개념 |
| Entity | - 고유식별자를 가지는 객체다. - 자신의 생명주기를 가진다. - 도메인의 고유한 개념을 표현하다 - 예: 주문(Order), 회원(Member), 상품(Product) |
| Value | - 고유식별자를 가지지 않는다. - 하나의 값을 표현할때 사용한다. - 다른 밸류 타입의 속성으로도 사용된다. - 예: 주소, 우편번호 |
| Aggregate | - 연관된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. - 주문과 관련된 엔티티를 하나의 애그리거트로 묶을수 있다. |
| Domain Service | - 도메인 모델의 영속성으르 처리한다. - 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인서비스에서 로직을 구현한다. |
| Repository | - 도메인 모델의 영속성을 처리한다. - DB 전담으로 처리한다. |
Bounded Context
- 서비스를 독립적으로 구현했을때 문제가 없이 돌아가는 영역이다.
- 모델안에서 경계를 정한다.
- 즉 업무를 구분해 놓은 것이다.
- 도서구매 에서는 주문, 배송이 각각의 Bouded context 이다.
Aggreate Pattern
- 연관된 Entity 와 Value Object 의 묶음
- Root Aggrate 는 대표적인 엔티티이다.
- Aggrate 에 접근할수 있는 것은 Aggrate Root 뿐이어야한다.
Aggregate Root
- Aggregation Root 란 수문장 또는 접근하기 위한 최상의 객체라고 생각하면된다.
- 아래 그림에서 OrderItem 에 접근 하려고 하면 반드시 Order 를 통해서 접근을 해야 된다.
- 그렇게 함으로써 안정성을 보장하며 Bounded context 내에서 접근만 가능하기 때문에
이해가 쉽고 유지보수성도 높아 진다.
728x90
반응형
댓글