[DDD] 도메인 모델 패턴 , Aggregate 모델링(1)

Aggregate 패턴은 도메인 모델 패턴이라는 거대한 개념에서,  좀더 세분화 된 모델링을 할 수 있다.

거대한 도메인 모델 패턴에서  적당히 쪼개야 하는데 Aggreagte개념으로 좀더 세분하게 쪼개는 것이다.

도메인 모델은 행위 + 자료구조를 통해 비지니스 로직을 구현한다.

 

도메인 모델은 POJO로 구성한다.

 

 

Aggreate가 뭘까?

서비스에서는 행위를 기준으로 도메인을 호출하는데

이를 서비스 단위로 Aggregate단위로 묶는것이다. 몇가지 타입을 공통으로 모델링을 해서 사용하라고 가이드를 한다.

 

Value object 란 뭘까?

 

DTO와 비슷해 보이지만, DDD에서는 해당 valueobject는 DTO와 다르다.

개념적으로 완전한 하나를 표현하고, 고유의 식별자를 가지지않는다.

저 3가지 중에 Color는 Valueobject이다 식별자가 없기 때문이다.

 

Person에는 id,firstName등등이 있는데, 결론부터 말하면, 2번째는 Valueobject가 아니다.

3번째는 ValueObject이다.

 

2번째 처럼 설계를 하는 경우, email에 유효성 검증이 어렵다.

즉, 이상한 String 이 들어와도 유효성 검증할 수있는 방법이 어렵다.

물론 생성자에 임의의 코드나 별개의 검증 처리 방식을 추가할 수 있지만

그럴바엔 3번째 VO를 사용해서, 하는 편이 좀더 설계적인 측면에서 좋다.

 

좋은 이유는 

1. 유비쿼터스 어어를 사용할 수 있고

2. 명료적이고, 의도를 정확히 전달 할 수 있다.

3. 유효성 검사 및 비즈니스 도메인 개념을 표현 할 수 있다.

4. 또한 각각의 유효성 검증에 대한건 각각의 VO에서 검증로직을 추가하면 훨씬 보기 편하다

5. 수정이 아닌, 값을 변경하면 삭제 + 생성 만 가능하기 때문에 로직상 이슈가 발생할 일이, 또한 유지보수가 간편해진다.

 

 

Entity란 ?

모든 도메인의 필수 구성요소이다.

도메인의 고유 개념 표현

다른 객체와 구별할 수 있는 식별자이다.

쉽게 얘기하면, 테이블 설계와 같은 개념이다.(Member,Person)

자신의 생명주기를 가진다.

데이터와 함께 기능을 제공하는 차이가 있다.

 

 

그림이 작아서 잘 안보일 수도있겠지만

JPA 와 유사하게 도메인 주도하에, 여러가지 설계를 할 수 있다.

Order라는 도메인 하위에 changeShippingInfo를 두어서, 새로운 SHippInfo를 끼우는 방법이 될 수도있고

각각의 연관을 나눠서 관리를 하고

상수로 설계를 하는 부분은 상수로 설계를 진행하면.된다.

 

Order라는 큰 개념에서 외부서비스로 해당 정보를 변경하는 것이 아닌

내부에 메소드를 두어서, ShippinInfo라는 객체를 갈아끼우는것이 DDD와 다른 설계의 차이라고 이해하면 편하다.