Work Objects란 무엇인가?
도메인 스토리텔링 연구 No. 9
<도메인 스토리텔링에 문법 입히기> 편을 올리고 나서 우리회사 CTO님을 통해 뵈었던 이상민 CTO님 댓글이 달렸다. Advanced Use Case라는 표현에서 UML을 표기법으로 쓰던 시절(?) 경험이 드러나는 질문이다. 나는 짧막하고 즉흥적인 답변을 올렸다.
문서화 도구로 전락하면 안된다
몇 시간이 지나지 않아 펼친 책에서 아래 문구를 보지 않았더라면 이글을 쓰지 않았을 것이다.
현대 애자일의 정수인 유저 스토리는 원래 의도인 흐름과 피드백 메커니즘이 아닌 문서화 도구로 쓰이고 있었다. <프로젝트에서 제품으로> 73쪽
유스케이스도 그 기원은 에릭슨에서의 사업적 성공으로 명성을 얻었다고 들었다. 하지만 UML로 흡수된 후에 쓰이는 모습을 보면 문서화 도구에 머물고 말았다. <프로젝트에서 제품으로> 저자에 따르면 애자일 진영에서 유스케이스에 해당하는 유저 스토리 역시 문서화 도구로 전락했다고 한다. 도메인 스토리텔링은 아마도 이를 극복하기 위한 선구자들의 시도처럼 보인다.
그림이건 글이건 이런 종류의 작업은 설계서가 아니라 의사소통 촉진에 쓰여야 한다. 최근 동료와 함께 보낸 경험에 따르면 (아직 짧지만) 일단 제대로 쓰고 있는 듯하다. Use Case와 domain storytelling을 내가 현장에 적용하는 일 사에에는 너무 긴 간극과 다른 맥락이 있어 설명이 불가능하지만, 이런 사건을 계기로 페이스북 답변과 지난 글 모두에 설명없이 사용했던 Work Object 설명을 해보자.
Work Objects 란 무엇인가?
먼저 <도메인 스토리텔링> 책 내용을 인용한다.
Actors create, work with, and exchange work objects (see Figure 2.2) such as documents, physical things, and digital objects. They also exchange information about work objects. The pictographic language does not distinguish between work objects and information.
예를 들어 문서나 물리적 사물 혹은 디지털 개체 들이다. 액터가 이를 생성하거나 대상으로 일을 하거나 교환한다. Work object 자체도 다른 Work object와 정보를 교환할 수 있다. 객체 지향 설계 경험이 있는 분은 쉽게 적응할 수 있을지 모른다. 객체 지향의 세계에서는 모든 것이 객체와 메시지의 교환이니까.
특이한 점은 도메인 스토리텔링이 채택한 그림 형태의 언어(pictographic language)에서는 정보와 Work object를 구분하지 않는다는 점이다. 아래 그림에서 movie ticket 두 개의 심볼이 다른 점이 힌트가 아닐까 싶다.
파라미터와 실제 대상을 똑같이 그리나?
책의 다른 부분에서 왜 그런지 추정할 수 있는 그림이 하나 있었다. 영화를 보려는 사람(movie-goer)이 popcorn을 달라고 할때(그렇다, 거리두기가 풀려 이제 팝콘을 먹을 수 있다.. ㅋㅋ)는 정보다. 하지만 슷자 3 이후로 전달받는 popcorn은 진짜 팝콘이다. 물리적 사물인 것이다.
매력적이다! 프로그램을 하는 사람이면 앞의 팝콘은 파라미터이고, 뒤의 팝콘을 출력물(return value)로 봐도 좋다. 엄밀한 표기로 유형 구분을 하는 것이 아니라 소통을 원활하게 하면서 어떻게 개발해야 할지 힌트를 충분히 준다. 빙고! 동료와 공유하고 도메인 스토리텔링에 문법 입히기에 업데이트(Commit)를 해야지.
지난 도메인 스토리텔링 연구
3. 도메인이 무엇인가요?
