소개

DDD + CQRS로 구현하면 업무 지식이 도메인 서비스에 편향되어 버리는 생각이 듭니다만 맞습니까?
구체적인 예를 생각하면서 검토해 보았습니다.

전제

여기 에 기재되어 있는 것과 같이, 원가, 이익률, 매매치에 대한 계산을 실시할 수 있는 상품이라고 하는 집약을 생각합니다.
이익률은 상품이나 연도에 따라 바뀌므로 인터페이스를 준비하고 교환할 수 있도록 합니다. (I 이익률 취득)
UML처럼 쓰면 아래 그림의 이미지입니다.


이 도메인에서 이익률 계산의 비즈니스 지식을 어디에 구현해야 하는지 고려합니다.
계산 방법은 여기 참조.

엔티티에 구현

위 그림과 같이 상품 팩토리를 통해 상품을 생성합니다. 이 때 필요한 도메인 서비스를 주입합니다.
판매 가격 등의 취득은 엔티티를 통해 실시합니다.
판매 가격을 계산하지만 실제 처리 장소가됩니다.
그러나 엔티티 안에 기술해 버리면, 다른 장소에서 이익률 계산을 하고 싶어졌을 때에 곤란합니다.
예를 들어 이익률이 n%였을 때의 원가와 판매가의 일람을 화면에 표시하고 싶은 경우,
CQRS적인 쿼리로 엔티티를 거치지 않고 DTO에 싸서 값을 취득했을 때에 이익률 계산을 하려고 생각해도 할 수 없습니다.

도메인 서비스에 구현

위 그림과 같이 이익률 계산용의 인터페이스를 준비해(1 인터페이스 1 메소드라도 좋을지도), 상품 팩토리에, I 이익률 계산과 I 이익율을 취득하는 것을 주입합니다.
이렇게 하면 엔티티에서도 이익률 계산할 수 있고, DTO로 정보를 손에 넣은 장소에서도 I이익률 계산을 주입하면 사용할 수 있습니다.
다만, 그렇다면 일부러 엔티티에 도메인 서비스를 주입하지 않고 DTO 때와 같고 필요한 때에 I 이익률 계산을 주입하여 사용하면 좋지 않을까 생각합니다.

값 객체에 구현

다른 패턴으로서 값 객체에 구현하는 것도 검토해 보았습니다. 이렇게 하면 DTO로 정보를 취득했을 때에도 이익률 계산은 할 수 있습니다.
그러나 이것이라면, 만약 이익률 계산의 계산식이 변경된 경우라든지, 교환이 필요하게 된 경우에 힘들 것입니다.
(인터페이스로 실장하고 있으면 실처리의 교환은 편하다. 값 오브젝트에 주입하는 것은 힘들다

요약

위와 같이 엔티티 외부에서도 사용하는 업무 지식은 도메인 서비스에 구현할 수밖에 없는 것일까.
엔티티 내에는

쿼리 시스템에서 사용하지 않음

자신의 정보를 사용하여 계산할 수 있습니다

같은 업무 지식밖에 둘 수 없는 것 같습니다.

도메인 서비스도 도메인 중이기 때문에 도메인 모델 빈혈증이 아닌가?