추가 전용 이벤트 저장소로 인해 추가 전용 코드베이스가 생성됩니까?

Question

이벤트 소싱을 사용하여 응용 프로그램을 구현할 때 작동중인 지속성 엔진은 이벤트 저장소입니다. 즉, 과거 시제의 순서 또는 발생에 대한 이벤트의 추가 전용 로그입니다. 응용 프로그램을 통해 이벤트를 간단히 재생하면 언제든지 상태를 재현 할 수 있습니다.

내 관심사 -이 추가 전용 이벤트 저장소가 불가피 추가 전용 코드베이스로 이어질하지 않는 이유는 무엇입니까? 코드를 제거하거나 코드를 변경하더라도 응용 프로그램이 일련의 이벤트를 재생할 수 없게되는 경우 어떻게 코드베이스를 유지 관리 할 수 ​​있습니까? 소스 코드 줄 수가 계속 줄어들 수 있습니까?

비즈니스 규칙을 수정해야한다면, 아니면 초기에 응용 프로그램의 초기에 불쾌한 버그로 인해 금지 된 상태가 될 수 있다면 어떨까요? 결함이있는 코드를 무기한으로 보존해야합니까? 물론 이러한 많은 문제는 이론적으로 이벤트 버전 관리, 이벤트 스키마, 스냅 샷 버전 관리 등을 사용하여 처리 할 수 ​​있습니다. 그러나 이벤트 소싱이 그 시점에서 부담이되지는 않았습니까?

이벤트 소싱은 최소한 프로덕션 환경에서는 상당히 새로운 기술입니다. 2 년 넘게 사용하고있는 애플리케이션이 거의 없다고 생각합니다. 10 년 후에는 어떻게 생겼을까요? 엔터프라이즈 애플리케이션의 비현실적인 시대는 아닙니다.

Answer 1

내 관심사 -이 추가 전용 이벤트 저장소가 필연적으로 추가 전용 코드베이스로 이어지지 않습니까?

아니, 그것은 당신의 구현에서 분리되는 추가 전용 스키마을 의미한다.

비즈니스 규칙을 수정해야하는 경우, 또는 어쩌면 응용 초기에 불쾌한 버그로 인해 금지 된 상태가 될 수 있다면 어떨까요? 결함이있는 코드를 무기한으로 보존해야합니까?

사실 - 도메인은 내구성 표현과 분리되어 있습니다.

예, 설계에 통합해야하는 몇 가지 일반적인 시나리오가 있습니다. 이벤트 이력의 초기 오류를 보완해야 할 수도 있다는 생각과 같습니다.

근본적으로 현재 상태 만 저장하는 경우와는 근본적으로 다릅니다. 데이터베이스에 잘못된 상태의 집계가있는 경우 해당 위치에서 업데이트하십시오. 필드의 일부를 변경해야합니다.

아이디어는 이벤트 소싱에서 동일합니다. 당신은 원하지 않는 상태를 만들어내는 이벤트 스트림을 가지고 있습니다. 당신이 있어야 할 상태에 도달하기 위해 어떤 추가 이벤트가 필요한지 알아냅니다. 타다. 물론

, 이러한 문제의 많은 수 - 이론 - 스냅 샷 등 그러나이 이벤트 소싱은 그 시점에서 부담이 될하지 않은 버전 이벤트 버전 관리, 이벤트 스키마를 사용하여 처리 할 수?

아니요?예, 모델을 적극적으로 발전시킬 수 있도록 스키마에 유연성을 설계해야하지만 핵심은 현재 상태를 저장하는 것과 다르지 않습니다. 은 여전히 ​​마이그레이션해야합니다.

하지만 다른 레버를 가지고 놀 수도 있습니다.

아마도 더 많은 초기 설계 자본이 필요합니다. 스키마 수명과 레코드 책이 모델의 여러 개정판에서 데이터를 누적한다는 사실을 생각해야합니다.

그 은이 아닙니다. 모든 발에 맞는 신발입니다. 훌륭한 메시지 스키마 설계는 투자입니다. 해당 스키마의 소비자 (이 경우 실제로 모델과 가입자를 의미 함)가 독립적으로 발전 할 필요가 없다면 그 투자는 타당하지 않을 수 있습니다.