[도메인 주도 설계 철저 입문] 도메인 서비스

"도메인 주도 설계 철저 입문" 도서를 정리한 내용입니다.

 

4. 부자연스러움을 해결하는 도메인 서비스

서비스란?

 

소프트웨어 개발에서 말하는 서비스

: 클라이언트를 위해 무언가를 해주는 객체를 말한다.

도메인 주도 설계에서 말하는 서비스

1) 도메인을 위한 서비스

2) 애플리케이션을 위한 서비스

 

 

 

 

 

 

도메인 서비스란?

• 값 객체나 엔티티 같은 도메인 객체에는 객체의 행동을 정의할 수 있다.
• 예를 들어 사용자명으로 사용할 수 있는 문자열의 길이나 문자의 종류에 제한이 있다면 이러한 지식은 사용자명을 나타내는 값 객체에 정의될 것이다.
• 그러나 시스템에는 값 객체나 엔티티로 구현하기 어색한 행동도 있다. 도메인 서비스는 이런 어색함을 해결해주는 객체다.

값 객체나 엔티티에 정의하기 어색한 행동

• 현실에서는 동명이인이 충분히 있을 수 있지만, 시스템에서는 사용자명을 중복으로 사용할 수 없게 하는 경우는 많다.
• 사용자명에 중복을 허용하지 않는 것은 도메인의 규칙이며 따라서 도메인 객체에 행동으로 정의돼야 한다.
• 그렇다면 이 규칙은 구체적으로 어떤 객체에 구현돼야 할까?

도메인 서비스는 가능한 한 피할 것

• 앞서 보았듯이, 모든 행위를 도메인 서비스에 구현하는 것도 가능하다. 마음만 먹는다면 얼마든지 도메인 객체를 모두 빈혈 도메인 객체로 만들 수 있다.
• 물론 도메인 서비스로 옮기지 않으면 어색한 행위도 있다.
• 어떤 행위를 값 객체나 엔티티에 구현할지 아니면 도메인 서비스에 구현할지 망설여진다면 우선 엔티티나 값 객체에 정의하는 것이 좋으며 도메인 서비스에 행위를 구현하는 것은 가능한 한 피해야 한다.
• 도메인 서비스를 남용하면 데이터와 행위가 단절돼 로직이 흩어지기 쉽다.
• 로직이 흩어지면 소프트웨어가 변화에 대응하는 유연성이 저해돼 심각하게 정체된다.
• 소프트웨어의 변경에 대한 유연성을 확보하려면 중복되는 코드를 제거하기 위한 노력을 한시도 포기해서는 안 된다.

정리

• 도메인에는 도메인 객체에 구현하기에 자연스럽지 못한 행위가 있다. 이런 행위는 여러 개의 도메인 객체를 가로질러 이뤄지는 처리인 경우가 많다. 도메인 서비스는 이럴 때 활용하는 객체다.
• 서비스는 이모저모로 편리한 존재다. 도메인 객체에 구현해야 할 행위를 마음만 먹는다면 모두 서비스로 옮길 수 있다.
• 빈혈 도메인 모델이 생기지 않으려면 어떤 행위를 어디에 구현해야 할지 세심하게 신경 써야 한다.
• 행위가 빈약한 객체는 절차적 프로그래밍으로 빠지기 쉽기 때문에 도메인 지식을 객체의 행위로 나타낼 기회를 읽게 된다.