🧐TIL

[DDD] 명세, Specification

date
Mar 13, 2023
thumbnail
slug
ddd-specification
author
status
Public
summary
“도메인 주도 설계 철저 입문”을 읽으며 공부한 내용을 정리합니다.
type
Post
category
🧐TIL
tags
TIL
DDD
Architecture
updatedAt
Jun 18, 2023 05:57 AM

명세

어떤 객체가 특정 조건을 만족하는지 평가하는 코드는 일반적으로는 객체 내부의 메소드로 정의할 수 있지만 평가 절차가 복잡하거나 평가 자체를 대상 객체의 메소드로 두는 것이 자연스럽지 못한 경우도 있다.
앞서 ‘사용자 이름 중복검사’ 같은 경우 도메인 모델에 검증 메소드가 있는 것이 부자연스럽기 때문에 애플리케이션 서비스에 구현을 했었다. 그리고 이 경우 조건이 비교적 간단했기 때문에 애플리케이션 서비스에 구현을 해도 문제가 없었다.
하지만 만약 조건을 만족하는지 확인하기 위해 리포지토리를 통해 정보를 조회해야하고 조건이 객체 유형에 따라 달라지기까지 한다면 애플리케이션 서비스에 부여될 책임이 많아지고 도메인 로직이 애플리케이션 서비스에 노출될 가능성도 높다.
이를 위한 대책으로 명세(Specification)를 사용할 수 있다.

명세의 사용법

명세는 객체가 조건을 만족하는지 확인하는 역할만을 수행한다. 도메인 규칙을 담고 있으므로 도메인 객체에 해당하지만 엔티티나 값 객체 대신 리포지토리를 다루고 문제를 해결할 수 있도록 돕는다.
객체를 평가하는 코드를 객체 내부에 구현하면 객체의 역할이 불분명해지고 원래 의도가 잘 드러나지 않게 된다. 이럴 때 목적에 따라 코드를 명세로 분리하면 객체 자신의 의도도 잘 드러나게 되고 평가 조건 또한 명세로 드러나게 되는 장점이 있다.

리포지토리 사용의 자제

명세는 값 객체나 엔티티 대신 리포지토리를 다루도록 하는데, 명세 또한 엄연히 도메인 객체에 해당되기 때문에 명세에서 리포지토리를 다루는 것은 부적절할 수 있다.
이런 경우 명세에서 리포지토리를 통해 직접 데이터를 조회하는 대신 애플리케이션 서비스에서 검증에 필요한 특화된 데이터 컬렉션 객체인 일급 컬렉션 (first-class collection)에 정보를 주입해서 사용하는 방법을 선택할 수 있다.