소개

DDD + CQRS로 구현하면 비즈니스 지식이 도메인 서비스에 불과합니다. 로 고민하고 있을 때,
경계가 붙은 컨텍스트를 DCI로 생각해 본다에서 DCI에 대해 공부했는데,
쿼리로 취득한 DTO에 롤을 주면 좋지 않아? 라고 생각했기 때문에 투고해 보겠습니다.

전제

DDD + CQRS로 구현하면 비즈니스 지식이 도메인 서비스에 불과합니다. 에서 말한 이익률 계산에 대한 계속입니다.

자꾸 쓰면
과 같이 이익률 계산에 관한 메소드를 엔티티에 넣어 버리면 쿼리 측에서 사용하는 것이 어렵다는 이야기입니다. 그래서 도메인 서비스에 둘 수밖에 없을까라고 생각했습니다. 하지만 이익률에 관한 방법이 늘어나면 무엇을 사용하면 좋은지 모르게 될 것 같은 생각이 들었습니다. 도메인 서비스에 흩어져 있던 이익률에 대한 지식을 역할로 요약 거기서 만난 것이 DCI라는 생각. 자신 중에서는 데이터 클래스에 역할(역할)을 주는 이미지입니다. 문맥에 따라 롤을 전환하여 유스 케이스를 실현합니다.
이런 식으로 I이익률을 취득하든지 I이익률 계산이라든지 이익률에 관한 업무지식이 도메인 서비스에 흩어져 있던 것을 I이익률을 계산하는 역할이라는 역할로 정리해 버립니다. 그렇게 하면 DDD + CQRS로 구현하면 비즈니스 지식이 도메인 서비스에 불과합니다.

그러나 엔티티 안에 기술해 버리면, 다른 장소에서 이익률 계산을 하고 싶어졌을 때에 곤란합니다.
예를 들어 이익률이 n%였을 때의 원가와 판매가의 일람을 화면에 표시하고 싶은 경우,
CQRS적인 쿼리로 엔티티를 거치지 않고 DTO에 싸서 값을 취득했을 때에 이익률 계산을 하려고 생각해도 할 수 없습니다.

심지어 DTO를 정의 할 때

같이 I이익률을 계산하는 롤을 계승해 버리면 쿼리측에서도 업무 지식을 무리없이 사용할 수 있는 생각이 듭니다. 요약 엔티티에서만 사용하는 비즈니스 지식은 엔티티에 구현 쿼리 (CQRS)에서도 사용하는 비즈니스 지식은 도메인 서비스로 구현됩니다. 업무 지식으로서 롤(역할)로서 정리할 수 있다면 롤을 준비한다 라고 생각했습니다만 어떨까요.