결론부터 말씀드리면 '이벤트스토어를 활용해 내가 원하는 View 를 만들어 내기란 여전히 턱없이 내공이 부족하다.' 입니다.
먼저 이벤트스토어에 대한 이야기부터 해보려 합니다. 그 다음 반복적으로 만들고 부수면서 느낀 점 이야기 해볼까 합니다.
이벤트 스토어란 무엇일까?
이벤트 스토어가 없던 시절의 우리는 데이터베이스에 어떤 행위의 결과값만 포함시켜왔습니다. Actor에 의해 만들어진 어떤 결과물을 의미합니다.
그렇다면 이벤트란 무엇일까요?
사내에서 이벤트라는 용어를 비개발자분들에게 설명하기 위해 사용된 장표를 가져왔습니다.
이벤트는 특정시점에 발생한 어떤 사건을 의미합니다.
그러므로, 이벤트 스토어는 특정시점에 발생한 사건을 저장하는 것을 의미합니다.
이것이 가져다는 주는 이점은 무엇일까요?
1. 바로 위에서 언급한 과거 내역을 확인할 수 있다는 것
2. 언제든 내가 만들고자 하는 뷰를 만들어 낼 수 있다.
3. 커뮤니케이션의 핵심 도구가 될 수 있다.
4. 개발 패러다임을 변경함으로써, Mental Shift 가 될 수 있다 (x축으로만 생각하다가 y축으로 생각하기?)
이렇게 좋음에도 불구하고 왜 많은 회사는 이벤트스토어을 적용하는 것을 대단히 힘들어할까요?
직접 만들어보고 부셔보면서 느낀 점은. 위에서 언급한 장점 4번이 되기까지 초반에 개발의 난이도가 심하게 가파르다고 생각합니다.
왜?
아주아주아주 러프하게 생각하는 것만 이야기해보면 다음과 같습니다.
이벤트를 DB에 저장한다면 어떤 이벤트를 저장해야 될까? 그 이벤트는 최소한의 필드로 채울 것인가? 최대한 많은 필드를 담을 것인가?
이벤트를 DB에 쌓는다면 변경된 이벤트 내역만 어떻게 가져올 것인가? 가져온 이벤트는 어떻게 처리할 것인가? 어디에 최종적인 ViewData 를 저장할 것인가? 이벤트를 DB에 쌓는데, 메세지 순서가 보장받지 못한다면 어떻게 해야될까?
벌써부터 위에서 질문한 내역의 답변만 생각해도 머리가 아프고 결정해야될 사항이 많습니다.
이런 문제를 하나씩 해결하면서 이벤트스토어를 어떻게든 구축했다면 문제가 없을까요?
이제 하나씩 View 를 만들어 내고자 하는데, 무엇이 문제로서 우려되는 부분일까요? 물리적으로 작성해야만 하는 코드가 정말 많습니다. Relay 모듈, ViewGenerator, View, ViewDatabase 까지. 이미 4개의 모듈을 만들기 위한 코드를 만들어내야만 합니다. 비지니스 로직은 사라지고 오직 이벤트만 존재하기 때문에 코드는 비교적 간단해집니다. 그러나 여전히 물리적으로 작성해야 할 코드가 너무 많습니다.
---
이제 드디어 본론으로 들어가겠습니다.
반복적으로 View 만들고 부수면서 느낀 점은 무엇인가?
이벤트스토어를 만들고, 뷰를 만들고 부수는 행위를 계속하면서 느낀 점은 "Mental Shift" 가 얼마나 중요한지 다시한번 알 수 있었습니다. 우리는 객체지향이라 불리는 협력, 역할, 책임, 메세지 등의 용어를 활용해 각각의 컴포넌트가 유기적으로 동작되는 것을 중요하게 여깁니다. 하지만! 여전히 우리의 뇌는 객체지향이기 전에 절차지향이고, 데이터 프로세스적 사고방식을 가질 수 밖에 없다고 생각합니다. 이 또한 이유를 묻는다면 간단합니다. 코드를 생각하면서 치고 있나요? 그렇다면 이미 우리는 데이터 프로세스적 사고방식을 가졌다는 의미이다. 그리고 우리는 사람입니다. 우리는 하나의 생각만으로도 이미 벅찬 존재입니다.
그러나, 만약 이벤트스토어의 이벤트꾸러미가 존재하고 그안에서 마치 레고 조립하듯이 메세지를 조합해 뷰를 만들어 낸다면 어떠할까요?
이것은 데이터 프로세스적 사고방식인가요? 객체지향 사고방식인가요? 아마도 비평하실 수 있지만- 이벤트꾸러미 그 자체가 이미 객체지향을 충족시켜주고 있다고 생각합니다. 실제로 이벤트꾸러미에서 레고 조립하듯이 메세지를 조합할 적에는 위에서 언급한 데이터 프로세스적 사고방식을 할 이유가 없습니다. 그냥 데이터가 거기 있으니까- 그 데이터의 행위를 (더하기, 빼기) 를 통해서 원하고자하는 결과값을 도출해내면 된다고 생각합니다.
코딩을 생각하면서 하지 않습니다. 저는 이것이 굉장히 중요하다고 생각합니다. 코딩을 왜 생각하면서 해야될까요? 이 순간부터 이미 우리는 도메인에 집중하고 있는 것이 아니라, 데이터에 집중하게 유도한다고 생각합니다.
[참고자료]
https://microservices.io/patterns/data/event-sourcing.html
Microservices Pattern: Event sourcing
Use event sourcing, which persists aggregates as a sequence of domain events
microservices.io
https://docs.microsoft.com/ko-kr/azure/architecture/patterns/event-sourcing
이벤트 소싱 패턴 - Azure Architecture Center
추가 전용 저장소를 사용하여 도메인의 데이터에 대해 수행된 작업을 설명하는 일련의 이벤트 전체를 기록합니다.
docs.microsoft.com
'가치관 쌓기 > 개발 돌아보기' 카테고리의 다른 글
| 엄청 많은 속성을 가진 객체를 테스트해야 한다면 어떻게 해야될까?(with. test Data Builder) (0) | 2022.09.09 |
|---|---|
| 적절한 마이크로서비스를 도입하는 시기는 언제일까? (8) | 2022.07.09 |
| REST API 에서 URL은 무슨 의미인지 살짝 맛 본 썰!! (0) | 2022.05.19 |
| Layered Architecture 의 단점이 무엇이라고 생각하는가? 두번째 이야기 (4) | 2022.04.13 |
| 나쁜 냄새가 드는 한마디 "잠깐만요 코드좀 볼게요." (0) | 2022.03.06 |
댓글