답변:
시스템 아키텍처도 변경하기로 결정하면 이벤트 소싱의 이점을 최대한 활용할 수 있습니다. DDD와 결합 된 CQRS 스타일 아키텍처로 가면 적어도 내 의견으로는 이벤트 소싱의 진정한 이점을 얻을 수 있습니다.
대규모 시스템에서 잘 작동하는 이벤트 저장소를 구축하는 것은 쉬운 일이 아닙니다. 모든 데이터를 재생하는 것은 실제로 비용이 많이들 수 있습니다. 재생해야하는 데이터의 양에 따라 다릅니다. 그러나이를 해결하는 데 도움이되는 기술이 있으며 그 중 하나가 스냅 샷의 개념입니다. 재생은 특정 시점에서만 수행됩니다. 이벤트 저장소가 시스템에 가져 오는 이점은 매우 중요합니다. 시스템에서 발생한 모든 것을 재생할 수 있으므로 모든 순간의 모든 데이터가 훌륭합니다. 분석, 버그 재현, 통계에 대해 생각하십시오.
훌륭한 이벤트 저장소가 많이 있으며 마지막 이벤트 저장소 는 어제 이벤트 저장소로 릴리스되었으며 실제로 좋은 것 같습니다.
요청 된 데이터로 DTO를 구축하기 위해 시스템의 쿼리 부분에 대해 기존 데이터베이스를 유지할 수 있습니다. 이 데이터베이스는 응용 프로그램 및 클라이언트의 쿼리 요구를 고려하여 구성하고 최적화 할 수 있습니다.
CQRS 아키텍처의 이점과 이벤트 소싱과의 결합에 대한 자세한 기사를 작성했습니다. CQRS, 도메인 이벤트 및 DDD 검토를 확인할 수 있습니다 .
이벤트 소싱의 주요 질문은 "당신의 기록은 무엇입니까"입니다.
귀하의 기록이 이벤트 스트림 인 경우 아무런 문제가 없습니다. 당신의 기록이 당신의 "엔티티 모델"이라면, 문제는 모든 곳에서 일어나기 시작할 것입니다. 이것의 일부는 "엔티티 모델을 잃어버린 경우 이벤트 스트림에서 다시 만들 수 있습니다"라고 말할 수 있다는 것입니다. 이 질문에 긍정적 인 반응을 보인 경우, 이벤트 로그가 기록입니다.
이벤트 소싱을 사용하는 대부분의 사람들이 읽기 모델을 사용한다는 것을 기억하는 것도 중요합니다. 이 모델은 데이터를 쿼리하는 데 사용됩니다. 이것은 3nf 엔터티 모델보다 1nf 모델과 비슷할 것입니다. 쓰기 만 허용되는지 판별하기 위해 집계 상태를 다시 가져 오기 위해 이벤트 만 재생합니다.
여전히 모든 엔티티가있는 DB를 가질 수 있습니까? 또는 메모리에서 각 엔티티의 최신 버전을 가져 오기 위해 애플리케이션을 시작할 때마다 이벤트를 재생해야합니까?
답은 응용 프로그램의 요구 사항에 따라 다릅니다. 나는 그것이 두 가지 방법을 모두 수행하는 것을 보았다.
소규모 회계사를위한 매우 성공적인 소프트웨어 패키지는 시작할 때마다 CQRS 로그를 읽습니다. 원시 데이터의 양이 상대적으로 적으므로 느린 컴퓨터에서도 시작 시간이 1 분 미만이었습니다. 그들은 관행이 대중화되기 전에 10 년 이상 CQRS를 해왔다. 그들은 더 큰 시스템으로 인해 어려움을 겪지 않고 클라이언트 데이터를 계속해서 업그레이드 할 수 있다는 것을 깨달았을 때 좋은 일을하고 있다는 것을 알았습니다.
쿼리 측을 구현하기 위해 RDBMS 기능에 의존하는 대량의 데이터 및 / 또는 시스템의 경우, 이벤트 소스 데이터의 "현재 뷰"에 대한 데이터베이스가 있습니다 (여러 개의 뷰를 가질 수도 있음). 이 방법의 장점은 익숙한 기술을 사용하여 쿼리 측을 작성할 수 있다는 것입니다.