모델 저장소의 의미와 구현
도메인 모델링 세미나 6
<도메인 모델링 활용의 기본 아이디어>편에서 이야기 한대로 도메인 스토리텔링을 하는 동료가 도메인 모델링을 더욱 포괄적으로 사용하는 방법을 함께 연구하고 있다. 그러던 중에 모델링 결과를 보관하는 저장소를 함께 정의하는 시간을 보냈는데, 그때 경험 중에 다시 떠오르는 내용을 기록으로 남겨본다.
모델 저장소Repository란 무엇인가?
모델을 보관하는 공간을 Repository라고 말한다. 나 스스로 혹은 구두로 논의하는 사람들과는 '모델 저장소'라고 해도 크게 뜻이 달라지지는 않지만, Repository라는 말이 조금 더 정확하게 느껴진다. 내 경우는 90년대 말에 썼던 Rose라는 도구를 통해 처음 익힌 표현이기 때문이기도 하지만, 그 경험이 확정되어서 IDE(개발도구)를 코드와 프로젝트 Repository로 쓴 경험이나 요즘 일상 도구인 두레이를 프로젝트 리포지토리라고 인식하는 경험과 연결된 문제다.
하지만, 저장소라고 해도 큰 문제는 없다. 다만, 굳이 둘의 차이에 대해 따져 물은 이유는 동료에게 Repository에 대해 설명할 때, 내 인식 속에서 Repository의 핵심 기능을 둘로 설명한 이유다.
모델링 결과물의 보관
모델링 결과물 찾기
저장소라는 이름을 쓰면 찾기에 대한 쓰임새가 약화된다는 인상을 받는다. 나는 그 느낌을 동료에게 전하기 위해 DDD 책의 Repository 빌딩블록 이미지를 찾으려고 구글링을 했었다.
도서관 사서 이미지로 대표하는 메타포는 방대한 결과물 보관과 검색 역량을 함축적으로 보여주는 좋은 상징이다. 결론적으로 이런 의미로 쓰지만 Repository와 저장소를 같은 의미로 두고 글을 쓴다.
모델링 저장소의 구현
우리는 실전에서 실용적으로 모델링을 쓸 방법을 연구하는 것이기 때문에 기존의 모델링 도구가 제공하는 저장소를 사용할 생각은 없다. 모델러 입장에서 저장소는 일차적으로 본인의 기억을 보조해주는 수단이 되어야 한다. 그런 점에서는 Rose를 쓸 때도 소수의 훈련된 사람들만 저장소를 구축할 수 있던 경험이 떠오른다. 저장소 자체를 내 손으로 구성하는 경험이 어쩌면 모델링 자체에서 차지하는 비중이 적지 않을 수도 있다.
암튼 우리는 일상에서 우리가 쓰는 소통 도구인 두레이를 기준으로 했다. 그렇게 되면 두레이가 갖고 있는 중첩 제약을 지켜야 하다. 무슨 말이냐면 두레이는 프로젝트 하위에 2단계의 업무 구조를 갖는다. 그래서, 프로젝트 자체가 저장소의 최상위(root)라면, 그 하위에 산출물이 담길 수 있는 단계는 2개 뿐이라는 말이다. 이는 마치 2단계의 메뉴 구조속에 결과물을 담는 일과 유사하다.
우리는 각 단계를 두레이 태그로 구분해서 찾기로 했다. (찾기 위해 보관할 때 태그를 잘 붙여줘야 한다.) 최상위 산출물은 UseCase에 담는다. 그리고 DomainStorytelling 결과는 각 UseCase 하위에만 존재할 수 있다.
이 규칙의 의미를 문장으로 풀면 대략 이렇다.
모델링 결과는 시스템의 쓰임새(usecase)에 담긴다(혹은 묶는다). 그리고 쓰임새에 대한 구체적인 시나리오는 Domain Storytelling 표기법으로 묘사하고, 그 결과를 쓰임새에 단위로 보관한다.
지난 도메인 모델링 세미나 연재
5. 아주 이상적인 아키텍처
