[7장] 이벤트 버스 아키텍처

[chhw130]

🧐 Question

1. 이벤트 버스 아키텍처??

이벤트 버스 도입부에

1. 뷰는 초기 상태를 렌더링한다.
2. 사용자가 폼을 작성하고 엔터키를 누른다.
3. DOM이벤트가 뷰에 의해 캡처된다.
4. 뷰는 ITEM_ADDED 이벤트를 생성하고 버스로 보낸다.
5. 버스는 새로운 상태를 생성하는 이벤트를 처리한다.
6. 새로운 상태가 컨트롤러로 전송된다.
7. 컨트롤러가 뷰를 호출해 새로운 상태를 렌더링한다.
8. 시스템이 사용자 입력을 받을 준비가 됐다.

의 흐름으로 흘러갈 때 이벤트 버스는 아키텍처적 요소고, 도메인 관련 코드를 포함해서는 안 되기 때문에 잘못된 것이다.라는 말은 5번의 과정에서 직접적으로 모델(상태)을 건드리고 있기 때문에 잘못됬다는 건가요?? (비즈니스 로직을 직접적으로 처리하고 있기 때문??)

2. 이벤트 버스와 redux의 패턴

이벤트 버스와 유사한 느낌으로 redux를 얘기하는데, 우리가 평소에 알고 있는 redux는 flux패턴의 단방향 흐름이라 좀 혼동이와 두 패턴을 비교해봤습니다.

Redux와 이벤트 버스 패턴의 공통점

• 중앙 관리: Redux의 store는 이벤트 버스처럼 모든 상태를 한 곳에서 관리합니다. 이 중앙 스토어에서 상태를 전파하므로, 전역에서 특정 상태의 변화를 감지하고 반응할 수 있습니다.
• 상태 변경 이벤트에 대한 구독: Redux는 상태가 업데이트될 때마다, 특정 컴포넌트들이 구독(subscribe)을 통해 상태 변경에 반응할 수 있습니다. 이 구독 패턴은 이벤트 버스가 이벤트를 발행하고 구독자들이 해당 이벤트에 반응하는 방식과 유사합니다.

Redux와 이벤트 버스 패턴의 차이점

• 단방향 데이터 흐름: Redux는 데이터 흐름을 단방향으로 유지하며, 상태 업데이트는 반드시 reducer를 통해 일어나야 합니다. 이벤트 버스는 보통 데이터 흐름이 단방향으로 제한되지 않고, 필요에 따라 양방향으로도 구현될 수 있습니다.
• 불변성: Redux는 상태를 불변하게 유지하면서 상태를 변경할 때마다 새로운 상태 객체를 생성합니다. 반면, 이벤트 버스 패턴에서는 상태의 불변성이 보장되지 않으며, 데이터를 직접 변경할 수도 있습니다.
• 미들웨어와 확장성: Redux는 redux-thunk나 redux-saga와 같은 미들웨어를 통해 비동기 로직과 사이드 이펙트를 관리할 수 있습니다. 이벤트 버스 패턴 자체에는 이런 확장성이 없으며, 주로 단순한 이벤트 전달과 상태 반응에 사용됩니다.
• Reducer를 통한 상태 업데이트 제한: Redux는 상태를 직접 변경하지 않고, 반드시 action을 통해 리듀서 함수로 전달해야 상태가 변경됩니다. 반면, 이벤트 버스는 이런 제약 없이 이벤트 핸들러를 통해 직접 상태를 수정할 수 있습니다.

redux가 이벤트 버스 패턴을 일부 수용하고 단방향 데이터 흐름과 불변성 개념을 추구해서 좀 더 상위호환 느낌이 나는것 같습니다.