Event Driven Architecture 고찰 - (1) 왜 필요한가?

서론

백엔드 팀 내 Event Driven Architecture 스터디를 진행 중에 있다.

이론 학습과 실습을 병행했는데, 첫 실습은 경계 콘텍스트를 나눠보자는 것이었다.

경계콘텍스트는 용어의 의미가 변하거나, 관심사가 완전히 달라지는 구역으로 EDA의 '이벤트'를 정의하는데 사용된다.

 

하지만 책에 서술된 내용은 모호하게 느껴졌고, 이렇게 나누는 것이 과연 맞는건지에 대한 의문도 있었다.

비즈니스의 전체 흐름을 시각화한 뒤 자연스럽게 경계를 찾기 위해 이벤트 스토밍을 진행했다. 

관련된 자료를 리서치하고 실습을 진행하며 아쉬웠던 점을 복기하면서 "그래서 왜 EDA가 필요한가"에 대한 의문까지 조금 더 다가가게 되었다.

 

 

과정

miro 를 사용하여 각자 이벤트 포스트잇을 생성하고 시간순에 따라 정렬하며 액터, 커맨드, 외부시스템, 정책 등을 정해진 규칙(색상, 위치)에 따라 추가했다. 이벤트 까지는 비교적 순조롭게 진행이 되었지만, 외부시스템에 내부의 다른 서버, 외부 솔루션의 어떤 범위까지 포함해야 하는지, 액터에 유저는 기업회원, 일반 회원을 분리할 것인지 여부에 대한 논의가 명확하게 결론지어지지 않았다.

아쉬웠던 점

정책 포스트잇을 붙이는 데 어려움을 겪음. 코드로만 유추 가능

백엔드 코드, 용어에 아직 갇혀있다는 느낌을 받음. 사용자 여정 관점에서 분석하기 어려움

 

그래서 PM, 기획팀, 마케팅 팀도 같이 하면 좋겠다는 생각이 듬.

그러면 그 분들의 시간을 쓰는건데, 어떻게 설득하면 좋을지 고민함.

이 때 EDA의 필요성을 개발팀 뿐 아니라 전사적으로 생각하게 바뀌게 됨.

 

Discussion

EDA, DDD, MSA, 왜 필요한가?

결국엔 KPI 인 것 같음.

개발팀은 CQRS를 통해 성능 이슈를 해결하고 시스템의 복잡도를 낮추어(분할정복 알고리즘 관점) 이득.

기획팀은 언어가 통일되어 프로젝트 진행 속도가 빨라져서 이득

마케팅 팀은 이벤트로 구성된 OLAP을 활용하여 개발팀 공수 없이 다양한 데이터를 자유롭게 활용하게 되어 이득

 

더 나아가서..

목적 조직 필요성을 체감함. 모든 팀원이 같은 목적을 가지고 비슷한 비즈니스 이해도를 가지면 서비스 운영이 원활할 것 같음.

콘웨이의 법칙과도 결이 맞음.

 

DO NOT:

• 기업 회원 서비스
• 일반 회원 서비스
• 관리자 서비스

 

DO:

• 공고
• 광고
• 지원
• 회원

 

참고

https://www.youtube.com/watch?v=DY3sUeGu74M

https://www.youtube.com/watch?v=sLG5n_pXWK0

https://www.youtube.com/watch?v=gihxS6eE1DM

https://helloworld.kurly.com/blog/event-storming/

Database Driven Development에서 진짜 DDD로의 선회, 이벤트 스토밍 -2-