입력 유효성 검증
- 일단 서비스의 책임은 아니다.
- 책은 입력 모델(input model)(서비스 DTO)이 이문제를 다루도록 하는 예제를 설명한다.
비즈니스 규칙 검증
- 서비스와 도메인 엔티티는 비즈니스 규칙 검증의 책임을 공유한다.
- 일반적으로 검증을 위해 모델에 접근할 필요가 있는 규칙인 경우 비즈니스 규칙이라고 판단할 수 있다.
Rich domain model vs Anemic domain model
풍부한 도메인 모델
- 애플리케이션의 코어에 있는 엔티티에서 가능한 많은 도메인 로직이 구현된다.
- 엔티티들은 상태를 변경하는 메서드를 제공하고, 비즈니스 규칙에 맞는 유효한 변경만을 허용한다.
빈약한 도메인 모델
- 엔티티 자체가 장히 얇다.
- getter, setter 메서드만 포함하고 어떤 도메인 로직도 가지고 있지 않다.
- 즉, 도메인 로직이 서비스에 구현돼 있다는 것
서비스의 리턴값
- 입력과 비슷하게 출력도 가능하면 각 유스케이스 (서비스 로직)에 맞게 구체적일수록 좋다.
- 맥락에서 반환 할 수 있는 가장 구체적인 최소한의 값이다.
- 이런 고민에 정답은 없지만 유스케이스를 가능한 구체적으로 유지하기 위해서는 계속 고민해야한다.
- 유스케이스 간에 같은 출력 모델을 공유하는 것은 지양하자
- 유스케이스가 강하게 결합되고 출력 모델이 점점 커지게 된다.
- 같은 이유로 도메인 엔티티를 출력 모델로 사용하고 싶은 유혹도 견뎌야 한다.
읽기 전용 유스케이스 (쿼리)
- 쓰기가 가능한 유스케이스(커맨드)와 분류하는 것이 좋을 수 있다.