brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Jul 11. 2022

도메인 모델링 활용의 기본 아이디어

도메인 모델링 세미나 2

<도메인 모델링? 비즈니스 모델링 어떻게 하나요?>편을 쓰고 나서 지인 두 분이 모델링 학습을 하는 자리에 동석했다. 두 분이 의기투합하여 앞으로 6개월간 꾸준히 만나 도메인 스토리텔링을 글로 읽는 방법을 고민해보겠다고 하셨다. 나는 두 분의 헌신에 대해 나 역시 무언가 기여를 하고 싶어서 두 분의 노력이 6개월을 이어가면, 내가 문서로 만드는 일은 책임을 지겠다고 선언했다. 7/6 도메인모델 선언이라 이름 붙이고, 그 흔적을 페이스북에 박제하여 올렸다.


내가 알던 도메인 모델이 아니잖아?

이 모임은 애초에는 일민 형이 도메인 모델 읽기에 대해 알고자 훈장님을 만나 설명을 듣고자 했던 자리에서 출발했다. 사정이 생겨서 일민형은 훈장님은 서로 만나지 못했지만, 훈장님은 해당 지식을 전달할 수 있는 다른 기회를 원했다. 마침 이틀 전에 도메인 스토리텔링을 하던 동료가 최근 모델링에 대해 질문했던 일이 떠올라 두 분이 만나도록 주선했다. 그리고 나름 의미있는 시간을 보냈다.


그리고 나서 최초 당사자(?)였던 일민형에게 전화를 해서 물었다. 도메인 모델 작성 방법에 대해 왜 궁금해 했는지 물었다. 도메인 모델은 90년대 후반부터 2000년 중반까지 UML을 사용하던 시절 유행처럼 쓰이고 이후에는 지나간 유행이 되어 버린 느낌이었다. 그런 상황에서 느닷없이 도메인 모델을 공부하려고 하는지 궁금했다.


그의 설명에 따르면 개발자들사이에 두 가지 현상이 있다고 한다. MSA가 부상하면서 DDD 책이 다시 뜨고 있다고 했다. 그러면서 잊혀졌던 DDD 책이 다시 조명을 받고 있다는 것이다. 일종의 설계 패턴에 해당하는 빌딩 블록만 알던 개발자들이 모르던 내용을 다시 발견한다는 말이었다. 예를 들어 DDD의 도메인이 테이블과 연결하는 클래스나 DTO 정도 등을 보관하는 패키지(혹은 레이어) 작명에 쓰던 도메인이 아니라는 점을 깨닫는다는 이야기였다.


그런데 그래서 도메인 모델을 어떻게 만들까 궁금증이 생겨도 책 전반부에 소개한 UML은 요즘 개발자들은 배우지도 않으니 어찌 하냐는 말이었다. 그리고 책 뒷부분에 소개하는 BoundedContext 내용을 보아도 실제로 어떻게 활용할지 방법을 알기 어렵다는 것이었다.

나 역시 <MSA를 대하는 개발자의 필수 마음자세>편에서 밝힌 대로 적어도 도메인이나 BoundedContext 개념을 꼭 알았으면 하는 마음이 있었기에 반가운 소식이다.


도메인 모델링 활용

굉장히 반가운 현상인데, 일종의 DDD의 재발견이라고 말할 수 있겠다. 나는 일민형과의 대화 그리고 다른 두 분의 대화에서 모처럼 모델링에 대한 진지한 소통을 했다. 그리고 나서 몇 가지 아이디어를 끄집어 낼 수 있었다.


하나는 도메인을 구성하는 주요 구성요소와 그들의 관계는 집약해서 자주 보고 이야기하는 방법은 유익하다는 전제다. 나는 구체적인 실천 방안으로 다시 세 가지를 제안할 수 있다. 첫째는 표기법으로 UML 클래스도가 효과적이라 생각이다. 클래스도 형태로 도메인의 주요 개념들의 관계를 포착하여 지도로 만드는 일이 우리가 나아갈 방향을 안내한다. 지도나 차량 네비게이터 역할과 같은 것이다.

출처: https://brunch.co.kr/@graypool/82


다음은 지도를 모두가 볼 수 있는 곳에 붙여 두고 활발하게 소통할 수 있는 분위기를 만들어내야 한다는 것이다. 이는 보험회사에서 성과를 벽에 붙여 두는 일과 유사하다. 목표나 비전에 대해서 각자의 이해나 입장 차이를 확인하는 일은 협업을 하는데 필수적이다. 이때 모호한 표현이나 한쪽으로 치우친 정보보다는 함축적이고 포괄적인 시각화 결과물은 분명 대화를 자극하는 촉매제가 될 수 있다.


한편, 동료를 통해 도메인 스토리텔링을 실전에 활용하면서 확인한 분명한 쓰임새가 있다. 클래스도가 대신할 수 없는 표현 요소이다. 예를 들어 두 개의 서로 다른 입장에 공존하는 것을 묘사할 때 도메인 스토리텔링은 굉장히 유용했다. 명백하게 서로 다른 입장의 공존을 모두 인지하지 않는 상태라면 참여자들이 자기 입장에서 대화 내용을 듣는다. 그리고 자신이 이해하는 입장에서만 시시비비를 따지는 탓에 다른 사람의 입장에 대한 이해가 없어 갈등이 발생한다. 이때 동일한 개념이 다양한 Work object로 나타나는 것이 눈으로 드러나면 다양한 입장을 이해할 수 있게 되고, 갈등이 공감으로 바뀌는 장면을 목격했다.


앞으로 이러한 아이디어에 기초한 실천법에 대해 기회가 생기는대로 기록으로 남길까 한다.


지난 도메인 모델링 세미나 연재

1. 도메인 모델링? 비즈니스 모델링 어떻게 하나요?

작가의 이전글 생각에 끌려가지 말고, 생각을 다스리기
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari