도메인 이벤트 정의하기
디지털 코어의 시작 2
<Ubiquitous Language 만들 결심>을 올린 직후 디지털 코어 구현에서 UL을 시도할 부분이 생겼다.
도메인 이벤트 정의하기
일과 중에 혼란스럽던 관심사를 추려 내면서고 상호 이익을 기대할 수 있는 기록을 남기려고 애쓰며 아래 이슈를 등록했다.
그랬더니 영역을 침범하지 않고 위임하고 협업할 수 있는 경계점을 발견했다. 그게 바로 도메인 이벤트라는 단위(혹은 빌딩 블록)이었다.
개인의 축적 습관을 활용하여 사회적 축적을 만들어내기
나는 습관적으로 브런치 내 글 목록 중에서 검색을 한다. 빠르게 과거에 생각했던 아이디어를 복원할 수 있기 때문이다. <분산 트랜젝션 대신에 도메인 이벤트 MSA 패턴>편을 보자 바로 시간을 아껴주었다. 두레이도 그렇지만 브런치까지 나에게는 하드디스크처럼 기억을 확장해주는 도구가 되었다.
자연스럽게 축적의 시간이 떠올랐다. 일상을 기록하는 내 습관은 나의 기록물이 내 기억의 축적의 산물이 되도록 해준다. 일단 내 개인적으로는 '축적의 시간'을 읽으며 각오했던 습관을 익혔다. 이제 사회적으로 작동하도록 할 때다.
각설하고 다시 <분산 트랜젝션 대신에 도메인 이벤트 MSA 패턴>편으로 돌아가 아래 이미지를 보니 당시 기억이 떠올라 쉽게 무엇을 해야 할지 감을 잡을 수 있다. 범례의 첫 번째 내용을 보면 Domain event는 과거형으로 기록한 업무 프로세스 상의 사건이다.
즉, '~가 벌어졌어요' 중에서 유의미하게 관리할 요소가 무엇인지 정의를 해야 한다.
어떤 사건을 담을 것인가?
내 욕구는 아래 화면에서 출발했다. 특정 주기에 따라 합산되는 화면을 보면서 합산할 때 환율을 가져다가 한화로 바꿔서도 함께 보여주면 좋겠다는 생각이 들었다.
그렇다면, 필요한 도메인 이벤트는 '거래 금액과 건수를 ~ 주기로 합산했다'를 프로그래밍 요소에 맞도록 작명하면 된다. 위 범례를 보면서 개발자 출신으로 또 자극받는 부분은 이벤트 생성을 위해서는 Command도 정의해야 하는구나 하고 생각하는 정도다.
자 여기까지를 동료에게 전달하고, 그에게 피드백을 받을 수 있는 순간을 기다려보자.
UL과 도메인 이벤트
앞선 <Ubiquitous Language 만들 결심>과 이 글은 무슨 관련이 있을까? 측정을 언급한 부분을 제외하면 보편적인 UL의 우리 회사 버전을 만드는 일의 첫 삽을 뜨는 상황이라고 말할 수 있다.
내 글 검색 과정에서 <기부상태 UL로 만들어보기> 편이 결과로 나타났다. 지속되지 못한 과거의 비슷한 노력을 확인할 수 있었다. 내가 측정에 관심을 두는 이유는 바로 지속 가능성의 열쇠가 거기 있다고 보기 때문이다. 지속할 수 없다면 UL은 만들어도 의미가 없다. 언어는 소통에 쓰일 때만 도구로서 작용하기 때문이다.
