작동/트랜잭션 유형의 응용 프로그램에서 작업 할 경우 DDD가 자연 스럽다는 것을 발견했습니다. 그러나 나는 항상 합리적인 방법으로보고 유형의 함수를 처리하는 stucked입니다.도메인 기반 디자인은 어떻게보고를 처리합니까?
내가 말하는 내용은 보고서 작성에 한정되지 않고 비교적 복잡한 쿼리를 수행하는 기능입니다. (예 : 상인이 수행 한 모든 주문의 요약을 제공하거나 특정 재고가있는 거래 계좌에 대한 계정 요약을 표시하는 것). 그것들은 단순히 이러한 쿼리와 함께 사용되는 쿼리 또는 지원 기능 일 수 있습니다.
이러한 함수의 경우 SQL (또는 다른 쿼리 언어)에서 조인을 수행하고 관심있는 열을 가져 와서 마사지 된 결과 집합을 반환하면 매우 자연 스럽습니다. 그러나 DDD를 사용하면 그렇게 잘 진행되지 않을 것입니다. 특별한 저장소가 필요하거나 기존의 가장 관련있는 저장소가 특수한 "엔티티/값 개체"(특수 결과 집합)를 반환해야합니다. 이러한 종류의 특수한 엔티티는 실제로 도메인 의미가 없습니다.
의미있는 도메인 계층을 사용하려는 경우 다른 저장소에서 많은 추가 조회가 생성되고 도메인 또는 서비스 계층에서 많은 집계 작업이 발생하여 성능 저하가 쉽게 발생할 수 있습니다.
"DDD 경로"를 거치지 않고 DB에서 보고서 데이터를 가져 와서 표시 결과를 작성하는 이러한 종류의 기능에 다른 "경로"가 있다고 생각했습니다. 그러나 응용 프로그램을 불필요하게 복잡하게 만들뿐만 아니라 전통적인 DB 지향 개발에 익숙한 개발자가 적절하지 않은 경우에도이 경로를 사용하는 경향이있는 추가 경로를 제공합니다.
나는 그런 상황이 꽤 일반적이라고 생각했다. (보통 큰 시스템은 운영뿐만 아니라보고 및 조회 기능을 포함하지 않을 것이다.) 나는 사람들이 그것을 어떻게 다루고 있는지 알고 싶다.
솔직히 어느 것이 옳은지 결정하기가 어렵지만 CQRS를 사용하는 것이 가장 합리적인 것처럼 보입니다. (그리고 나는 domaindrivendesign.org에서도 가장 확실한 답변입니다) –