[DDD] 응용 서비스와 표현 영역 -2

해당 포스팅은 최범균 작가님의  도메인 주도 개발 시작하기 (P.202~206)를 읽고 정리한 글입니다.

 

응용 서비스의 역할

응용 서비스는 사용자(클라이언트)가 요청한 기능을 실행한다. 응용 서비스는 사용자의 요청을 처리하기 위해 리포지터리에서 도메인 객체를 가져와 사용한다. 표현 영역 입장에서 보았을 때 응용 서비스는 도메인 영역과 표현 영역을 연결해 주는 창구 역할을 한다.

 

응용 서비스는 주로 도메인 객체 간의 흐름을 제어하기 때문에 다음과 같이 단순한 형태를 갖는다.

public Result doSumeFun(SomeReq req) {
	// 1.리포지터리에서 애그리거트를 구한다.
    SomeAgg agg = someAggRepository.findById(req.getId());
    checkNull(agg);
    
    // 2.애그리거트의 도메인 기능을 실행한다.
    agg.doFunc(req.getValue());
    
    // 3.결과를 리턴한다.
    return createSuccessResult(agg);
}

public Result doSomeCreation(CreateSomeReq res) {
	// 1.데이터 중복 등 데이터가 유효한지 검사
    validate(req);
    
    // 2.애그리거트를 생성한다.
    SomeAgg newAgg = createSome(req);
    
    // 3.리포지터리에 애그리거트를 저장한다.
    someAggRepository.save(newAgg);
    
    // 4.결과를 리턴한다.
    return createSuccessResult(newAgg);
}

응용 서비스가 복잡하다면 응용 서비스에서 도메인 로직의 일부를 구현하고 있을 가능성이 높다. 만약 이렇게 된다면, 코드 중복, 로직 분산 등 코드 품질에 안 좋은 영향을 줄 수 있다.

 

응용 서비스는 트랜잭션 처리도 담당한다. 응용 서비스는 도메인의 상태 변경을 트랜잭션으로 처리해야 한다.

---

도메인 로직 넣지 않기

도메인 로직을 도메인 영역과 응용 서비스에 분산해서 구현하면 코드 품질에 문제가 발생한다.

 

첫 번째 문제는 코드의 응집성이 떨어진다는 것이다. 도메인 데이터와 그 데이터를 조작하는 도메인 로직이 한 영역에 위치하지 않고 서로 다른 영역에 위치한다는 것은 도메인 로직을 파악하기 위해 여러 영역을 분산해야 한다는 것을 알 수 있다.

 

두 번째 문제는 여러 응용 서비스에서 동일한 도메인 로직을 구현할 가능성이 높아진다는 것이다. 즉, 로직이 중복 될 수 있다.

 

만약 이렇게 된다면 소프트웨어가 가져야할 중요한 경쟁 요소 중 하나인 변경 용이성을 놓치게 된다.

---

응용 서비스의 책임을 명확히 구분하지 않으면, 어느새 로직이 이곳저곳 흩어져 응집도도 낮고 테스트도 어려운 구조가 되기 쉽다. 이번에 읽은 내용을 바탕으로, 다음 프로젝트에선 도메인 객체가 책임을 명확히 갖고 응용 서비스는 흐름만 담당하는 구조를 직접 적용해볼 계획이다. 특히 상태 변화가 있는 기능에는 트랜잭션을 명확히 걸어주는 것도 다시 신경 써야겠다.