왜?
- DDD 개발 예시를 알기위해서
- DDD의 정확한 예시를 알기위해
도메인 기본 지식
- 도메인 = 문제의 영역
- 도메인 모델 -> 엔티티와 값객체로 나눔
- 엔티티 - 식별값이 존재
- 값 객체 - 식별값이 없음
- 보통은 루트 엔티티 + 값 객체로 구성되어 하나의 애그리거트가 된다.
애그리거트
- 애그리거트는 하나의 Repository, 하나의 Transaction 단위를 가지는 집합이다.
- 다음과 같이 하위 도메인 모델들의 기능들의 상태변화 및 비즈니스 로직을 구현하고있다. 따라서 루트 애그리거트를 통하여 하위 도메인 모델의 상태변화를 일으키도록 해야한다.
- 예시
- 주문(루트)
- 주문리스트
- 발송상태
- 주문(루트)
- 추가적으로 ID값을 이용하여 다른 애그리거트를 참조하는것을 추천한다. -> lazy로딩과 비슷함. 실제로 필요할때 정보를 가져오도록 쿼리하는 형태로 로직 구현
리포지터리와 모델 구현
- JPA를 활요한 리포지터리 구현
- 도메인 모델과 영속성 모델을 합쳐놓으신거같은데, 마지막에는 분리하는것을 추천하셨다.
- 다양한 JPA 활용법 포함
스프링 데이터 JPA를 이용한 조회기능 (CQRS 관련에서 조회)
- JPA 활용법
- 페이징 활용법
응용 서비스와 표현 영역
- 응용 서비스 구현
- 응용 서비스의 매개변수는 비즈니스로직+ 입력 검증 필요
- 에그리거트 찾음 -> 에그리거트.도메인로직 -> 결과리턴
- 응용 서비스와 도메인 서비스 구별법
- 도메인 서비스는 도메인 데이터 값 활용 + 변경을 한다. 따라서 데이터와 비즈니스로직이 바로 붙어있어야하고 캡슐화되어있어야한다.
- 도메인 로직이 응용 서비스에 있다면, 모든 응용 서비스들에 중복 검증 코드가 생기므로 바람직하지않다.
- 응용 서비스는 한 책임을 여러개 가져가는거 보다, 클래스를 분리하여, 각자의 책임을 가져가는 것이 좋다.
- Controller -> ChangePasswordService-> password 도메인모델의 검증호출
- 표현 영역의 역할
- 표현 영역에서는 입력에 대한 검증
- 반드시 응용 서비스 호출 DTO로 전환해줘야한다.-> 표현 영역의 DTO그대로 활용시 사이드 이팩 발생가능
도메인 서비스
- domain에 속함
- 도메인 서비스는 다음과같을 때 활용한다.
- 도메인 서비스는 하나의 에그리거트에서 처리하기 어려운 도메인 로직
- 도메인 모델 하나에 담기 어려운 경우
- 외부 서비스(포트) 이용해야할 경우
- 도메인 서비스를 에그리거트에 넣지말자.(많이 실수함)
- 에그리거트의 책임은 다른 에그리거트에 대한 책임을 포함하지 않는것이 바람직하다.