이벤트를 제대로 정의하려면 맥락을 잘 구축해야 한다
도메인 모델링 세미나 22
지인들과 대화에서 (소프트웨어) 모델링에 관한 이야기를 나눈 이후 벌어진 다양한 사건(events)으로 인해 <이벤트는 변경을 알리는 표준 프로그래밍 단위>라는 제목의 글을 만들어냈다.
사건을 뒤흔드는 더 큰 흐름
마침 페벗의 글에서 인용한 문구가 이 글을 쓰도록 유도했다.
EDA는 Event Driven Architecture의 약자다. 하지만, 베터코드에서 요즘 내 직업 일상과는 거의 무관한 단어였다. CTO님이 CQRS 샘플 코드를 보여주고, 나중에 보니 직원 위챗 채널에 다시 공유하기 전까지는 확실히 그랬다.
지난 글을 쓰고 나서 반복되는 사건들은 회사 EDA를 내 일로 바라보게 만들었다.
이벤트를 변경을 알리는 단위로 쓰면?
지난 글의 제목 <이벤트는 변경을 알리는 표준 프로그래밍 단위>는 이벤트를 변경을 알리는 프로그래밍 단위로 쓸 수 있을 것이라는 상상을 하게 했다. 나의 EDA는 이벤트를 프로그래밍의 변화를 알리는 표준 단위로 쓰는 약속이라고 할 수 있겠다. 아직은 구조나 구체적인 정의가 없으니 '약속'이라 표현했다.
여기서 아키텍처를 발전시키려면 개발을 해보거나 개발자와 협업을 해나가야 한다. 의사결정한대로 구현할 수 없다면 의사결정은 무용한 일이다. 그러니 개발 가능성과 효용성을 확인하며 아키텍처를 발전시켜야 한다.
아직 그런 시도를 하기 전인데 앞선 페벗이 인용한 책의 문구가 상상을 자극했다.
사건을 뒤흔드는 더 큰 흐름을 주시한다
이 문구는 내 머리속에서 다음과 같은 질문을 자아냈다.
이벤트 정의도 어려운데, 더 큰 흐름은 어떻게 찾을 수 있나?
사건을 뒤 흔드는 더 큰 흐름은 응용 프로그램이 쓰이는 그 동네에서 맥락을 파악해야 한다. 그 동네 혹은 파악한 맥락의 총합을 도메인이라고 할 수 있다. 도메인 스토리텔링이란 그런 맥락을 파악하는 방법의 한 가지 예시이다.
사건을 이해하려면 큰 흐름을 알아야 한다
프로그래밍 세계에서는 큰 흐름을 알 수 있다면 구조를 잡을 수 있다. 유동인구를 보고 상권을 분석하는 등의 간접경험을 떠올려보면 꼭 프로그래밍 세계에서만 그러한 것 같지는 않다. 암튼 인용한 문구 역시 큰 흐름을 알아야 사건을 제대로 이해할 수 있다는 말을 하는 듯했다.
출처: https://brunch.co.kr/@graypool/433큰 흐름은 어떻게 알 수 있는가? 흔히 소프트웨어 관련 서적에서 Domain Expert로 불리는 사람이 자주 등장한다. Expert라는 단어가 (영어가 네이티브가 아닌) 한국인에게는 편견을 갖게 하는 면이 있는데, domain expert란 그 업무에서 잔뼈가 굵은 사람을 말한다. 그런 사람을 우리말로 전문가라고 부르지는 않는다. 게다가 새로운 서비스를 기획하는 업무에서는 domain expert가 있을 리가 없다. domain expert는 주로 기업용 응용 프로그램 분야에 어울리는 말이다.
이벤트를 제대로 정의하려면 맥락을 잘 구축해야 한다
여기서 눈에 보이지 않는 지식 정보를 다루는 소프트웨어 분야의 특징이 잘 나타난다. domain expert가 정보의 소스를 제공하는 듯해도 과거에 하던 방식을 그대로 소프트웨어로 구현하지도 않고, 그럴 수도 없다. 옛날 표현으로 하면 '전산화' 혹은 '자동화'라는 목표가 더해지고, '디지털 전환', 'UX 개선', '프로세스 혁신' 등등 무어라고 부르던 IT 기술을 통해 더 나은 무언가(Ware)를 만드는 것이 최종 목적이다.
그래서, 종국에는 domain expert가 아닌 소프트웨어 전문가가 이벤트를 정의해야 한다. 만일, EDA를 적용한다고 하면 말이다. 지난 글에 기술한 대로 이벤트는 적합한 사실의 기록(factual record)이어야 한다.
그런데 어떻게 제대로 정의할까? 상상해보면 맥락을 훑어보며 이벤트를 넣고 빼고 이벤트를 묶거나 이벤트와 커맨드의 관계를 짓는 지난한 작업 속에서 맥락이 만들어진다. 맥락을 이렇게 정성 들여 만들다 보면 이벤트의 이름이 바뀌고, 역할이 정비되는 '정원관리'가 수행된다.
응용 프로그램의 맥락을 구축하기
잘 정의된 맥락은 어떻게 만들지도 고민해야 한다. 그 옛날 프로그래밍하던 시절에 스프링Spring이라는 오픈소스를 사용했다. 스프링을 처음 배울 때, Application Context라는 프로그램 요소는 스프링의 구동 방식을 이해하는데 기준이 되었다. 스프링 이전에 사용하던 EJB 혹은 Servlet의 Context 대신에 그냥 Application(a.k.a. POJO) Context로 작명한 프로그램 요소는 복잡한 제약조건이 없는 그냥 자바 프로그램 단위(POJO)로 어떻게 응용 프로그램을 구성할지에 대한 스프링 팀의 정의다.
요즘 거의 모든 자바 프로그램은 스프링 기반에서 돌아간다. 하지만, 스프링 팀이 도메인(응용 프로그램 현장)을 위한 응용 프로그램 맥락을 만들어줄 리는 없다. Application Context는 스프링으로 프로그램을 작성한 경우 구동할 방식을 강제했을 뿐이다. 그게 도메인에 적합한가는 스프링 사용자인 개발자에게 달려 있다.
맺음말
이 글은 프로그래밍에 대한 소재를 다뤘지만 개념적이다. EDA에 대해서 생각을 한발 더 나아가기 위한 글이다. 다음 단계로 나아갈지는 동료들과의 협업과 나의 일상에 달렸다.
지난 도메인 모델링 세미나 연재
5. 아주 이상적인 아키텍처
10. Repository 빌딩 블록에 대해 생각해보기
11. 맥락은 어떻게 표현할 것인가?
18. 도메인 모델링 절차에 대하여
19. 왜 도메인 모델링을 하는가?
