전술적 설계 - SERVICE
여러 애그리거트가 필요한 기능
결제 금액 계산 로직
상품 애그리거트: 구매하는 상품의 가격이 필요하다. 또한 상품에 따라 배송비가 추가되기도 한다.
주문 애그리거트: 상품별로 구매 개수가 필요하다.
할인 쿠폰 애그리거트: 쿠폰별로 지정한 할인 금액이나 비율에 따라 주문 총 금액을 할인한다. 할인 쿠폰을 조건에 따라 중복 사용할 수 있다거나 지정한 카테고리의 상품에만 적용할 수 있다는 제약 조건이 있다면 할인 계산이 복잡해진다.
회원 애그리거트: 회원 등급에 따라 추가 할인이 가능하다.
이 상황에서 실제 결제 금액을 계산해야 하는 주체는 어떤 애그리거트일까?정답 : 전부다 결제 금액 계산 로직에 관여하기 때문에, 정하기가 애매하다. (그렇기 때문에, 도메인 서비스가 필요하다)
도메인 서비스
한 애그리거트에 넣기 애매한 도메인 개념을 구현하려면 애그리거트에 억지로 넣기보다는 도메인 서비스를 이용해서 도메인 개념을 명시적으로 드러내면 된다.
응용 영역의 서비스가 응용 로직을 다룬다면 도메인 서비스는 도메인 로직을 다룬다. (디테일한 차이는 다음시간에~ )
도메인 영역의 애그리거트나 밸류와 같은 다른 구성요소와 비교할 때 다른 점은 상태 없이 로직만 구현한다.
서비스를 사용하는 주체는 애그리거트가 될 수도 있고 응용 서비스가 될 수도 있다.
애그리거트 메서드를 실행할 때 도메인 서비스를 인자로 전달하지 않고 반대로 도메인 서비스의 기능을 실행할 때 애그리거트를 전달하기도 한다.
특정 기능이 응용 서비스인지 도메인 서비스인지 감을 잡기 어려울 때는 해당 로직이 애그리거트의 상태를 변경하거나 애그리거트의 상태 값을 계산하는지 검사해 보면 된다.
도메인 로직이 애플리케이션 서비스에 넘어가지 않도록, 도메인 패키지 내에 존재하도록 하는 것이 도메인 서비스이다.
FACTORY (이 개념은 아직 잘 모르겠다..)
어떤 객체를 생성하는 일이 복잡하다면 FACTORY를 이용해 이것을 캡슐화할 수 있다.
생성자, 팩토리 클래스 포함해서 DDD 에서는 팩토리라고 부른다. (포괄적인 의미)
핵심은 "객체(애그리거트, 엔티티, 밸류 오브젝트) 를 어디서 생성할것인가?" 이다.
어떤 다른 곳에서 해당 객체를 생성할 때 생산자의 정보를 필요로 하는 것을 줄일 수 있다.
아울러 생산자와 생성된 객체 사이의 특별한 관계를 전해주기도 합니다.
Last updated