도메인 서비스의 구체적인 예시는 뭐가 있을까?

[java-saeng]

책에서의 예제는 잘 와닿지가 않습니다..
혹시 도메인 서비스를 사용하는 구체적인 상황이 어떤게 있을까요?

[seohy02]

책의 예제로는도메인 서비스는 값 객체나 엔티티로 구현하기 어색한 행동을 정의한다. -> 이름 중복 확인 예제가 있었어요!
저는 책의 예제처럼, 엔티티 메소드로 구현할 경우 이름 중복확인을 위해 특정 객체(생성할 객체 또는 이름 중복확인을 위한 별도의 객체)가 필요한 점이 어색하다고 생각하여 이 부분은 서비스로 이용하는 것이 좋다고 느껴졌었어요.

현우님이 생각하시기엔 어느 부분이 와닿지 않았는지도 궁금합니다~

[seohy02]

위 댓글을 쓸때는 제가 도메인 서비스에 대해 잘 이해하고 있지 않았던 것 같아요..! 지난 번 스터디때의 논의를 통해서, 그리고 책을 더 읽고나서 이해하게 된 부분을 한번 정리해볼게용

기존 Controller/Service/Repository 패턴에서의 Service는 도메인 서비스가 아닌 애플리케이션 서비스라고 할 수 있어요. (저는 이 Service가 도메인 서비스라고 착각하고 있었어요)
도메인 서비스는 애플리케이션 서비스에서 이용되는 비교적 작은 단위의 기능을 수행하는 메소드를 담고 있어요.

그동안 코드를 작성할 때 ex) UserService 이렇게 애플리케이션 서비스 하나만 작성했고 도메인 서비스를 위해 다른 ~Service 로 명명되는 코드 파일을 만들어서 로직을 담아본 적은 저는 없었어요. 그렇지만 �기존 코드를 되돌아보며 도메인 서비스로 여겨질 수 있는 부분들을 찾았어요.

제 기준에서는 보통 애플리케이션 서비스 메소드중 Controller에서 직접 사용하진 않고, 애플리케이션 서비스 내에서 private 메소드로 정의되어 서비스 내의 다른 public 메소드 내부에서 사용되는 기능들, 또는 위치가 애매하여 util이나 common 등으로 뺐던 메소드들이 있었어요.

예를 들면 Server 엔티티 내 flavor라는 필드에 값이 1vCPU_RAM2GB의 형식으로 들어오고, 이때 비즈니스 로직 중 객체의 flavor를 파싱하여 vCpu = 1, memory = 2 로 값을 도출해야하는 경우가 있었어요. 이 파싱하는 메소드는 Server 엔티티에서 구현하기 어색해요. 파싱을 위해 Server 객체 하나를 생성하는 것이 어색하기 때문이에요. 이러한 기능이 도메인 서비스로 구현될 수 있다고 생각이 들었습니다!

위 예시에 대해 어떻게 생각하시나용??

[seohy02]

이러한 맥락으로 위 제가 작성했던 이름 중복 확인의 경우 '사용자 생성 시 이름 중복 확인을 해야한다.' 라고 가정하면,

애플리케이션 서비스에 사용자 생성 기능이 있고, 도메인 서비스에 이름 중복 확인 기능이 존재하여
애플리케이션 서비스의 사용자 생성 메소드에서 도메인 서비스의 이름 중복 확인 메소드를 이용하여 중복된 이름이 존재하는지 확인한 후 생성을 수행하는 방식으로 구현될 수 있을 것 같아요!

[java-saeng]

위 예시에 대해 어떻게 생각하시나용??

제가 생각하기에는 해당 예시는 서버의 스펙을 저장하기 위한? 그런 느낌이 듭니다. (맞다 생각할게요)
그러면 저건 단지 파싱을 하는 것 같아서, 파싱을 해주는 Parser 클래스에 넣어주면 될 것 같다는 생각이 듭니다.
파싱하는게 도메인 로직이라고 하기에는 애매한 것 같아서요!

'사용자 생성 시 이름 중복 확인을 해야한다.'

이거는 사용자에 대한 도메인 로직 같아요! 예를 들면 생성자 안에서 validate 메서드를 호출하면 될 것 같은 느낌입니다!

[java-saeng]

제가 생각한 도메인 서비스는 A, B 객체가 서로 연결되어있지만, 어떠한 로직이 A에 대한 책임이라고 하기에도 애매하고, B에 대한 책임이라고 하기에도 애매할 때 사용하는 것 같아요.
그래서 도메인 주도 설계 철저 입문, 도메인 주도 설계 구현에서는 도메인 서비스가 많아질수록 궁핍한 도메인 모델이 될 수 있을 가능성이 높다고 한 것 같아요.

도메인 주도 설계 구현에서 나온 예제를 보면 A, B 객체가 서로 연관은 있지만 특정 도메인 로직이 A에 있어야 할 것 같은데 B에 있어서 어색하고 이런 느낌을 받아서 위와 같이 생각하게됐습니다!

[java-saeng]

DomainService

exist(User) {
 // 유저의 중복을 판단하는거는 이름 뿐이다.
 // 이름과 번호가 같아야 중복이다. 로 하면 이 코드만 변경하면 됨
 return repository.existByName(user.name) && repository.existByAge(user.number);
}

XXXService

if(!DomainService.exist(User)) {
      createUser()
}

[seohy02]

이번에 6장 애플리케이션 서비스를 읽으면서 도메인 서비스에 대해 더 잘 이해하게 되었어요! (지난 스터디 때 논의를 하면서, 6장을 읽기 전에 저희 나름 도메인 서비스를 알맞게 해석한 것 같긴해요 ㅎㅎ) 이해하게 된 내용을 요약해서 작성해봅니다~

• 도메인 서비스란 도메인 지식을 코드로 나타낸 도메인 객체
• 이러한 도메인 객체만으로는 이용자의 문제를 해결할 수 없음, 도메인 객체를 엮어 이용자의 문제를 해결할 수 있도록 하는 것이 애플리케이션 서비스
• 도메인 규칙은 도메인 객체에만 기술하는 것이 바람직하며, 애플리케이션 서비스에는 도메인 규칙에 대한 기술이 포함하는 것을 지양해야 함

ex) 사용자명 중복 금지 규칙

상황

• 사용자명 중복 금지 규칙은 도메인 규칙이다
• 애플리케이션 서비스에 사용자 생성 / 수정이 있다고할 때 생성과 수정 시에 사용자명 중복 확인을 해야한다.

구현

1. 사용자명 중복 확인 로직을 애플리케이션 서비스에 기술했을 때

• 동일한 코드가 여러 곳에 반복될 수 있다.
• 중복 금지 규칙이 변경되었을 경우 애플리케이션 서비스에서 해당 규칙이 작성된 코드를 모두 찾아서 직접 수정해주어야 한다.

2. 사용자명 중복 확인 로직을 도메인 서비스에 기술하고, 애플리케이션 서비스에서는 도메인 서비스를 통해서만 해당 규칙을 검사하도록 했을 때

• 같은 규칙을 구현한 코드가 여러 곳에 반복되는 것을 방지할 수 있다.
• 향후 수정이 필요한 경우 도메인 서비스 내의 한 부분만 수정하면 되므로, 수정이 필요한 곳을 빠뜨려 발생하는 버그를 막을 수 있다.