도메인 서비스

여러 애그리거트가 필요한 기능

도메인 영역의 코드를 작성하다보면 하나의 애그리거트로 해결할 수 없는 경우가 존재합니다. (지금 제가 하고 있는 투표 도메인도 마찬가지입니다.)

그런 경우, 다른 애그리거트를 현재 애그리거트 내에 넣으면 해결되긴 하는데, 이렇게 되면 애그리거트의 책임도 굉장히 애매해질 뿐만 아니라 비대해지게 된다.

이를 해결하기 위해서 도메인 기능을 별도 서비스로 구현하는 방법이 있다.

도메인 서비스

도메인 서비스는 도메인 영역에 위치한 도메인 로직을 표현할 때 사용하게 된다.

주로 다음과 같은 상황에서 도메인 서비스를 사용하게 된다.

• 계산 로직 : 여러 애그리거트가 필요한 계산 로직이나, 한 애그리거트에 넣기에는 다소 복잡한 계산 로직
• 외부 시스템 연동이 필요한 도메인 로직 : 구현하기 위해 타 시스템을 사용해야 하는 도메인 로직

계산 로직과 도메인 서비스

도메인 서비스와 도메인 영역의 애그리거트나 밸류와 같은 구성요소를 비교할 때 다른 점은, 도메인 서비스는 상태 없이 로직만 구현한다는 점이다.

이렇게 하게 되면, 할인 계산 서비스를 사용하는 주체는 애그리거트가 될 수도, 응용 서비스가 될 수도 있는 것이다.
만일, DiscountCalculationService를 애그리거트에게 전달하게 되면, 사용 주체는 애그리거트가 된다.

이렇게 되면 응용서비스는 이를 도메인 객체에게 넘겨주기만 하면 되는 것이다.

하지만, 이를 프레임워크 딴에서 주입받아서 애그리거트 내에서 관리하는 것은 좋지 않은 선택인 것 같긴하다.

그리고 도메인 서비스에 애그리거트를 넘기는 경우도 있다. (처음에 예시를 들었던 것과 같이) 이렇게도, 저렇게도 가능하지만, 도메인 서비스는 응용 서비스와 다른 개념이니, Transaction을 관리한다던가 이러한 행위는 삼가는 것이 좋을 것 같다. 그 의미를 명확히 하고, 책임 분리를 명확하게 하기 위해서 말이다.

외부 시스템 연동과 도메인 서비스

외부 시스템과의 연동을 책임지는 도메인 서비스도 만들 수 있다.

도메인 서비스의 패키지 위치

도메인 서비스는 도메인 로직을 표현하므로 도메인 서비스의 위치는 다른 도메인 구성요소와 동일한 패키지에 위치해야한다.

도메인 서비스의 개수가 많거나, 엔티티나 밸루와 같은 다른 구성요소와 명시적으로 구분하고 싶다면, domain하위에도 여러 패키지를 만들어도 괜찮다.

도메인 서비스의 인터페이스와 클래스

도메인 서비스의 동작이 외부와 연관이 되어 있다면, 마치 Repository처럼 인터페이스는 domain 영역에 두고, 구현체는 infra 딴에 두어서 구현해, 도메인 영역이 특정 구현에 종속되는 것을 방지 및 도메인 영역에 대한 테스트가 쉬워지게 된다.