DDD NoSQL 저장소 및 도메인 모델 대 뷰 모델

Question

DDD 패턴을 사용하려고 노력 중이며 영구 저장소로 LiteDB, RavenDB 또는 DocumentDB와 같은 NoSQL 데이터베이스 사용을 고려하고 있습니다.

나를위한 이점 중 하나는 관계형 DB를 통해 내 도메인 모델 (전체 집계)을 JSON 문서로 직렬화하고 도메인 모델에서 데이터 모델 매핑을 피하는 DB에 저장할 수 있다는 것입니다.

하지만 화면에 표시 할 목적으로 데이터를 읽는 것은 어떨까요? 내 UI는 뷰 모델을 기반으로 뷰를 표시하지만이를 구성하는 방법은 무엇입니까? 를 통해 문서 DB를 쿼리합니까? 내 도메인 모델을 만든 다음 모델을보기 위해 매핑합니까?

일반적으로 "도메인 모델을 쿼리에 사용하지 마십시오 (모델 읽기)"라고하기 때문에이 질문을드립니다.

Answer 1

내 관계형 DB에 비해 장점은 내 도메인 모델 (전체 집계)을 JSON 문서로 직렬화하고 도메인 모델에서 데이터 모델 매핑을 피하는 DB에 저장하는 것입니다.

그래, 좋습니다.

하지만 화면에 표시하기 위해 데이터를 읽는 것은 어떨까요? 내 UI는 뷰 모델을 기반으로 뷰를 표시하지만이를 구성하는 방법은 무엇입니까? 를 통해 문서 DB를 쿼리합니까? 내 도메인 모델을 만든 다음 모델을보기 위해 매핑합니까?

예. 재미있는 질문은 일 때 일 때입니다.

요청을 통해 동 기적으로 작업을 수행 할 수 있습니다.

같은 작업을 요청과 동 기적으로 수행 할 수 있지만 결과를 캐시하므로 동일한보기의 후속 쿼리가 더 빠릅니다.

백그라운드 작업을 사용하여보기를 캐시로로드하여 모든 쿼리가 빠르기 때문에 비동기 적으로 작동 할 수 있습니다.

기본 아이디어는 문서에 변경 사항을 기록 할 때마다 변경된 사항을 비동기 프로세스에 알리고 프로세스가 캐시 된보기를 업데이트하는 데 필요한 데이터를로드한다는 것입니다.

"캐시"는 예를 들어 최근 작성한보기 모델을 보유한 문서 저장소 일 수 있습니다.

캐시 된 뷰에는보기를 다시 작성해야하는지 여부를 요청할 때 확인할 수있는 메타 데이터가 포함될 수도 있습니다. RFC 7234은 캐시 메타 데이터를 생각할 때 시작하는 것이 좋습니다.

파블 (Pawel)에 따르면 쓰기 모델과 읽기 모델을 분리하는 것이 cqrs의 큰 테마입니다. 조용한 많은 문학이 있습니다. Martin Fowler's overview부터 시작하는 것이 좋습니다.

Answer 2

도메인 모델이 동작과 상태로 구성된다는 점을 이해해야합니다. 당신이 유지해야 할 유일한 것은 주입니다.

이 사실을 알게되면 집계 상태가 쿼리를 실행하는 데 무서운 것이 아니라는 것을 알게됩니다. 하지만 읽기 /보기 모델을 작성하는 데 리포지토리를 사용하면 안됩니다. 간단한 쿼리만으로 충분할 것입니다.도메인 객체 상태를 데이터베이스에 저장할 간단한 DTO (문서)로 분리하여 도메인 객체의 속성으로 유지하는 것이 편리합니다. 이것은 책에 표시된 것과 약간 다르지만 실제로는 잘 작동합니다. 충분한 캡슐화를하고 직렬화 및 지속성 테스트를 작성하지 않으면 걱정하지 않아도됩니다. This article은 상태 개체가있는 도메인 개체 섹션 아래에서 언급합니다.