개요
도메인을 중심으로 개발하는 방법론
그럼 도메인이란?
도메인이란 소프트웨어로 해결하고자 하는 문제영역을 말한다.
예를들어 배민같이 음식배달 중계서비스를 제공하는 어플리케이션이 있다면 다음과같은 도메인이 있을 수 있다.
1) 음식점 관리 도메인 : 음식점들을 카테고리별로 분류하고 순위를 선정한다.
2) 주문 도메인 : 고객은 원하는 음식을 주문할 수 있다.
3) 배달 도메인 : 배달기사와 음식점을 연결하여 고객에게 음식이 전달될 수 있도록 한다.
이러한 도메인을 중심으로 비즈니스행위와 결과물을 최대한 일치시켜 설계하는것이 바로 DDD(Domain Driven Design)이다.
DDD의 기본 요소들
1) Entity & VO
-
Entity : 엔티티의 가장 큰 특징은 식별성과 연속성을 가진다는 점이다.
예를들어 학생이라는 객체는 고유 id값이 있고, 학생끼리는 이 고유 id값으로 구분이 가능하다.(식별성) A라는 학생의 학점이 달라진다고 해서(연속성) 다른 학생이 되는것은 아니다. -
VO(Value Object) : VO는 식별성이 없고 상태를 중심으로 객체의 정체성을 부여한다. 같은 VO로 식별되려면 VO의 모든 값이 같아야 한다.
2) Bounded Context
같은 용어라도 하위 도메인마다 의미가 다를 수 있고 문맥(Context)에 따라 객체(Object)의 역할이 바뀔수 있다.
예를 들어 피자가 식탁위에 있을때와 길거리에 있을때 용도가 완전히 달라진다. 피자라는 객체는 서로 같지만 식탁위 피자는 오늘 저녁메뉴일 수 있으나 길거리 피자는 그냥 쓰래기에 불과하다.
도메인 모델링에서도 비슷한일이 발생한다. '상품'이라는 객체가 있다면 이름은 같아도 주문 도메인에서는 팔기위한 정보들이 담겨있을것이고 재고 도메인에서는 관리해야할 정보들이 담겨있을 것이다.
그래서 구분할 수 있도록 하위 도메인을 만들고 각 하위 도메인은 섞여선 안되므로 구분되는 경계를 만들어 줘야한다.
이처럼 구분되는 경계를 갖는 Context를 Bounded Context라고 한다.
3) Aggregate
Aggregate는 도메인 객체들의 집합이다. 그리고 이 집합을 대표하는 객체를 Aggregate Root라고 부른다.
예를들어 주문자, 주문할 상품, 결제라는 객체가 있으면 이 객체들은 '주문'이라는 Aggregate로 뭉칠 수 있으며, '주문'은 Aggregate Root가 된다.
외부객체는 Aggregate내의 객체로 직접접근을 할 수 없고 Aggregate Root를 통해서만 접근해야한다.
'주문' Aggregate Root를 예로 들면 회원객체는 주문상품이나 배송에 직접 접근할 수 없다. 대신 주문 Aggregate에 접근함으로써 배송이나 결제, 주문상품에 명령을 전달 할 수 있다.
참고자료
https://huisam.tistory.com/entry/DDD
https://frontalnh.github.io/2018/05/17/z_domain-driven-design/
https://medium.com/myrealtrip-product/what-is-domain-driven-design-f6fd54051590
