트리플 과제 중 생각이나서 과제 제출후 따로 리팩토링을 진행하면서 공부한 부분을 정리한 글입니다.
Event-Sourcing 패턴
기존에는 App 상에서 특정 로직을 처리한 이후 DB에는 해당 로직의 결과값만 담는식으로 진행이 됐다,
하지만이벤트 소싱방식은DB가 변경되는 순간의 모든이벤트를 저장한다.
기존 방식
Book Table에서 A Row를 삭제했다가, A Row를 삭제하는경우
DB상에서는 현재 시점의 최종 작업 결과가 A Row라는것을 확인 할 수 있다.
이벤트 소싱 방식
A Row를 삭제했을때, 생성했을때의 상태를 모두 확인이 가능하며, 상태 전체를 저장한다기 보다 A Row를 삭제했다 라는 형식의 이벤트 내용만 저장하는 방식
왜 CQRS인가?
유저와 회원관리만 있는 프로젝트에서 LMS기능이 추가되면 어떻게 추가할것인가?
-> 별도로 구현하여 추가한다.. 그에 걸맞는건 CQRS패턴
중요한점은 별도의 시스템으로 구현한다는것.
더 중요한것은 시스템이 커질수록 서로간의 의존성이 생기게 되는데 만약 의존성이 깊은 시스템이 고장나면 나머지도 전부 고장나버리기 때문에 분기가 중요하다.
CQRS
Command와Query를 분리하여 성능과 확장성 및 보안성을 높일 수 있도록 해 주는 아키텍처 패턴
다시 풀어쓰자면 CRUD중에서 CUD와 R을 구분하자는 이야기.
구분하는 이유는 우리가 DB로부터 데이터를 읽어오고 처리를 하게되면, 이미 그 사이에 데이터가 변경이 되엇을 가능성이 높다는것
CQRS는 이런 변경 가능성을 인정하고 R과 CUD사이에는 trade-off가 있다는것을 인정하는것이다.
DB
모든 서비스는 DB가 뿌리이기 때문에 DB가 맛이가면 서비스가 맛이간다
즉, Client - Web - DB끼리 통신을할때 DB에서 쓰고,읽기때문에 병목현상이 일어나게된다
대부분의 서비스는 Read가 Write보다 7:3~ 8:2로 더 많은데
이럴때 Read/Write DB를 분리하면 DB서버의 부하를 줄일 수 있다.
그래서 어떤식으로 진행중이니
기존에 과제를 진행했던건 전부 MySQL에 진행중이였다
만약 CQRS패턴을 쓰게된다면 CUD부분을 MySQL로쓰고 R부분을 mongoDB를 쓴다면 좋지않을까 라는 생각으로 진행중이다
