이 로직은 도메인 영역일까? 애플리케이션 영역일까?

프로젝트에 DDD를 적용하는 도중 겪었던 고민에 대해서 다룬 포스팅입니다.

개발할 때 도메인 영역에 넣을지 애플리케이션 영역에 넣을지 애매한 경우가 많았습니다.

먼저, 도메인 서비스에 대해서 간단히 알아보겠습니다.

🤨 도메인 서비스란?

책 “도메인 주도 설계로 시작하는 마이크로서비스 개발”에 의하면 도메인 서비스를 다음과 같이 설명합니다.

🧑🏻‍💻
도메인의 비즈니스 로직 처리가 특정 엔티티나 VO에 속하지 않을 때 단독 객체를 만들어서 처리하는 경우를 뜻한다.
도메인 서비스에서는 상태를 관리하지 않고 행위만 존재한다.
따라서 도메인 로직을 처리할 때 엔티티나 VO와 함께 특정 작업을 처리하고
상태를 본인이 가지고 있지 않고 엔티티나 VO에 전달한다.

책 “도메인 주도 설계 첫걸음”에서도 도메인 서비스를 비슷하게 설명하고 있습니다.

🧑🏻‍💻
도메인 서비스는 비즈니스 로직을 구현한 상태가 없는 객체다.
대부분의 경우 이런 로직은 어떤 계산이나 분석을 위한 다양한 시스템 구성요소의 호출을 조율한다.

즉, 도메인 엔티티와 도메인 서비스의 차이점은 도메인 서비스는 상태 없이 로직만 구현합니다.

도메인 서비스가 쓰이는 상황이 하나 더 있는데, 그 상황은 바로 외부 시스템을 연동할 때입니다.

다음은 애플리케이션 서비스에 대해서 간단하게 알아봅시다.

🤨 애플리케이션 서비스란?

책 “도메인 주도 설계로 시작하는 마이크로서비스 개발”에 의하면 애플리케이션 서비스를 다음과 같이 설명합니다.

🧑🏻‍💻
애플리케이션 서비스는 업무 흐름을 의미하는 유스케이스 흐름을 처리한다.

🤔 도메인 영역 vs 애플리케이션 영역

클린 아키텍처에서는 각 영역이 어떤 역할을 맡고 있는지 다음 그림으로 설명합니다.

내부 영역에서는 맨 안쪽에 도메인이 존재하고 도메인을 서비스가 감싸고 있습니다.

• 도메인 영역 : 핵심 비즈니스 개념과 규칙을 구현
• 서비스 영역 : 도메인을 호출해서 업무를 처리하는 절차 + 외부 영역과 연계

참고로, 데이터베이스 관련 처리를 하는 영역은 리포지터리가 맡고 있는데, 서비스 인터페이스 내에서 리포지터리를 호출하여 사용합니다.

도메인 영역과 서비스 영역 간의 관계를 구현할 때 참고할 패턴이 있는데, 트랜잭션 스크립트 패턴과 도메인 모델 패턴이 있습니다.

이에 관한 자세한 내용은 책 “엔터프라이즈 애플리케이션 아키텍처 패턴"에서 나옵니다.

간단하게만 설명하자면 다음과 같습니다.

• 트랜잭션 스크립트 패턴 : 서비스 영역에 비즈니스 로직의 책임이 있는 패턴
• 도메인 모델 패턴 : 도메인 영역에 비즈니스 로직의 책임이 있는 패턴

간단한 비즈니스 로직인 경우에는 트랜잭션 스크립트 패턴, 복잡한 로직인 경우에는 도메인 모델 패턴을 적용하는 것이 바람직하다고 합니다.

😲 결론

제가 내린 결론은 다음과 같습니다.

• DDD를 도입한 이상 최대한 코드를 객체지향적으로 짜는 것이 좋다고 생각합니다.
• DDD 역시 확장성을 고려하여 고안한 설계이기 때문입니다.

제가 경험했을 때 서비스 영역의 로직을 도메인 서비스로 옮기면 다음과 같은 장점이 있을 것 같습니다.

• 길었던 서비스 영역이 줄어들게 되어 가독성이 높아진다.
• 모듈화되기 때문에 테스트 코드가 작성이 용이해진다.
• 도메인 서비스로 옮겼기 때문에 재사용성이 증가한다.

🐻
사내 프로젝트인만큼 팀원들과 도메인 서비스를 사용할지 회의를 한 뒤, 적용했습니다.
현재는 해당 로직을 VO로 분리하여 정적 팩토리 메서드로 구현하였습니다.
도메인 서비스가 적용된다면 다음 포스팅은 적용한 사례에 대해서 재구성한 코드로 찾아뵙겠습니다.

레퍼런스

도메인 주도 설계로 시작하는 마이크로서비스 개발 - YES24

 

도메인 주도 설계 첫걸음 - YES24