DDD 표현 영역과 응용 영역

도메인을 제대로 만들지 못하면 요구사항을 충족하는 소프트웨어를 만들기란 힘들다는 것을 잘 알고있다.
도메인 영역은 기본 패시브로 잘 구현하되,
거기에 도메인에 활력을 불어넣어줄 표현영역, 응용영역도 잘 구현이 되어야 한다.

표현 영역

표현 영역은 사용자의 요청을 해석한다.

스프링으로 따져 생각해본다면 Controller로 생각하면 될 것 같다.

DDD에서 말하는 패키지 구조로 보면 interfaces가 될 것이다.

표현 영역은 URL, 요청 파라미터, 쿠키, 헤더 등등을 이용해서 클라이언트에서 원하는 작업을 받아서
응용 영역에 처리를 위임시킨다.

응용 영역

응용 영역은 표현 영역의 요청을 받아 처리를 하는 Service로 생각해볼 수 있다.

---

표현 영역에서 전달 받은 데이터는 일단 신뢰할 수 없는 데이터이므로,
값에 대한 검증이 있을 수 있고, 또 응용 영역에서 필요로 하는 데이터 타입으로 변환을 시켜주는 동작이 들어가야 한다.
그 후 응용 영역이 요구하는 객체를 생성하고 응용 서비스의 메소드를 호출한다.
그리고 작업이 완료되었을 때 반환되는 값을 토대로
응답 객체를 만들어서 알맞는 형식으로 응답을 내려준다.

응용 서비스의 역할

보편적인 응용 서비스의 구조는 이런식이다.

public Response applicationMethod(final long id) {
    //1.인프라 스트럭쳐에서 애그리거트를 불러온다.
    Domain domain = domainRepository.findById(id);

    //2. 애그리거트의 도메인 기능을 실행한다.
    domain.doSomething();

    //3. 결과를 반환해준다.
    return domain.toResponse();
}

조회해서 내려받는건 보통 이런식일거라고 생각한다.

그리고 생성이나 수정같은 경우에는 Request 요청 객체가 들어올때 유효성 검증을 실행하고,

그 후에 조건에 부합하는 경우에 생성, 수정을 해주면 된다.

---

단순 조회인 경우 서비스 레이어가 필요하지 않은 경우에는

Controller -> Repository 로만 구성해도 무방하다.

기존 Layered Architecture 로 구성했을 때, jpa 구현기술에 대한 의존이 있는 경우에

도메인이 인프라 스트럭쳐에 의존하게 된다.
DDD를 연습해보면서 느끼는 점은, 도메인에 대한 리포지토리를 인터페이스로 도출한 후에
구현체들을 인프라 스트럭쳐에 위치시키면 도메인이 구현 기술에 대한 의존이 없어지게 구성이 된다.
JpaRepository를 만든다고 한다면

DomainRepository <- DomainJpaRepository 로 의존이 반대로 흐르게 구성이 된다.

값 검증

값 검증은 표현 영역, 응용 영역 두곳에서 모두 수행이 가능하다.

• 표현 영역
  • 필수 값, 값 형식, 범위 등등을 검증한다. (@Valid나 @Validated)
• 응용 서비스
  • 데이터의 존재 유무와 같은 논리적 오류를 검증한다. (findById()의 orElseThrow 같은것들을 생각해보면 될듯????)

@RestControllerAdvice와 @ExcepitonHandler를 사용해서

요청 값에 대한 검증을 먼저 진행해준다.