도메인 주도 설계 - 이벤트

오랜만에 도메인 주도 설계 관련 포스팅을 합니다. 오늘 다루고자 하는 내용은 이벤트입니다. 이벤트란 과연 무엇이라고 정의할 수 있을까요?

도메인 주도 설계에서 이벤트란 과거에 일어난 일이라고 정의할 수 있습니다. 좀 더 구체적으로 얘기하자면 엔티티에 발생한 사건이라고 말할 수 있겠네요.

이벤트라는 것은 엔티티에 변화가 생겼기 때문에 이것을 누군가가 알아야 할 경우에 발생시킬 필요가 있습니다. 누군가는 Bounded Context가 되는 경우가 대부분입니다. 만약 아무도 해당 엔티티의 변화에 관심이 없다면 굳이 이벤트를 발생시킬 필요가 없겠죠.

예를 들어 볼께요. 다음과 같은 마이크로 서비스(=Bounded Context)가 있다고 생각해 보세요.

• 사용자 마이크로 서비스: 학생의 데이터를 관리합니다. 학생의 ID, 이름을 관리
• 수업 마이크로 서비스: 수업의 데이터를 관리합니다. 수업의 ID, 이름을 관리
• 수강신청 마이크로 서비스: 사용자가 수강 신청한 데이터를 관리합니다. 수강신청 ID, 사용자 ID, 수업 ID, 사용자 이름, 수업 이름을 관리

선생님 UI에서 다음과 같은 수강신청 리스트를 보여주는 리포트가 있고, 이 리포트는 수강신청 마이크로 서비스에서 제공된다고 생각해 보세요.

만약 사용자 이름이 사용자 마이크로 서비스에서 변경이 되거나, 수업 이름이 수업 마이크로 서비스에서 변경이 발생하면 수강신청 마이크로 서비스에 알려줄 필요가 있습니다. 이럴 경우 이벤트를 발생시키고, 수강신청 마이크로 서비스에서는 이 이벤트를 받아들여 사용자 이름 또는 수업 이름을 변경시켜, 올바른 데이터의 리포트를 보여줄 수 있게 됩니다.

굳이 그럴 필요 있을까라고 생각하시는 분들도 분명히 계실 겁니다. 사용자 ID와 수업 ID만 가지고 있으면 각각 마이크로 서비스와 통신하여 데이터를 가져오면 되지 않을까라는 얼핏 생각을 할 수 있는데요, 불가능하지는 않지만 굉장한 부하를 일으킬 수 있는 방법으로 추천되지 않습니다. 만약 보여주어야 하는 레코드 개수가 1000개라면 불필요한 네트워크 부하를 일으킬 수 있습니다. 최악의 경우는 Sort와 칼럼 필터링입니다. 사용자 이름에 대해 Sort 기능을 제공하고 사용자 이름 검색 기능이 들어가면, 감당 못할 네트워크 부하 및 엄청난 양의 DB 조인을 필요로 할 수도 있습니다. 이것은 마이크로 서비스의 단점 중에 하나이지요.

2020.02.11 - [개발자] - 마이크로 서비스 단점

마이크로 서비스 단점

그렇기 때문에 도메인 주도 개발, 특히 마이크로 서비스를 이용하는 경우에 이벤트 발생이 필요로 합니다. 오늘은 간단히 도메인 주도 개발의 이벤트에 대해 알아 보았습니다.