CQRS와 EventSourcing 기술을 보고

CQRS와 EventSourcing제대로 이해를 했나 모르겠는데

비슷한 생각을 하고 그런 설계를 잡으려고 했었는데, 당시에는 Hibernate ORM Envers라는게 있는줄 몰라서… 그 때의 설계는 ORM을 이용한 도메인 설계를 그대로 화면에 보여줄 수 있도록 하고 히스토리는 별도로 저장하는 구조였다.

예)를 들어 회원정보 엔티티에서 level 변동, password 변경 등에 대한 히스토리 저장이 필요하다.

RDBMS에서는 다음 엔티티의 현재상태만 저장 UserEntity { username : string password : string passwordChangeDate : date email : ref EmailEntity level : type { bronze, silver, gold, platinum, diamond, challenger } lastLoginDate : date }

로그는 별도 디비 또는 파일로 관리. user-password-change-history (password, passwordChangeDate) user-level-change-history user-lastLoginDate-history

이런방식으로 현재상태와 변경상태를 저장한다. 변경히스토리를 저장하는 부분을 하나하나코딩하면 안되고, 하이버네이트 인터셉터라던가 해서 데이터변경을 확인하고 로그를 남기도록 하는 추가기능이 필요하다.

이렇게 하는 경우 RDBMS의 데이터가 메인이기 때문에 변경기록이 남지 않게 되는 상황이 생길수도 있다. 중요한 데이터는 트랜잭션을 걸면 느려 계좌 밸런스를 저장하는걸 예로들걸 그랬나

지금 CQRS컨셉으로 제시하는 것을 보면 현재상태는 메모리디비같은데 저장하는 것 같은데 소규모시스템에서 생각 해 보면 RDBMS에 현재상태를 몽땅저장하는게 괜찮아보인다.

이정도로 중규모까지는 사용가능 해 보인다.

RDBMS의 업데이트를 과도하게 사용하는 부분이 문제가 되긴 할텐데…

어쨌든.. envers쓰면 쉽게 된다. http://hibernate.org/orm/envers/ …. 잘도 만들어 놨다. 이걸 왜 못찾았을까 좀만 더 찾아볼걸