도메인이 무엇인가요?
도메인 스토리텔링 연구 No. 3
MSA 기술이전 중인 고객사의 두레이에서 아래와 같은 글을 봤다. 굳이 끼어들 필요없는 대화인데...
끼어들기 혹은 함께하기
나는 습관처럼 위키피디아를 찾아서 다음과 같이 끼어들었다.
Domain-Driven Design 에서 말하길
우선, Eric Evan의 DDD 책에서는 뭐라고 말했나 찾아봤다. 마침 집에 책을 모셔두고 있었다.
Every software program relates to some activity or interest of its user. That subject area to which the user applies the program is the domain of the software.
번역은 파파고 결과를 보자.
앞서 인용한 함수의 도메인 혹은 정의역과 크게 차이가 없다고 느껴진다. Domain-Driven 이라는 말은 문제 정의를 잘하자는 말이기도 해서 새로울 것은 없다. 왜 문제 정의가 중요할까? 아래 예를 보자. 사용자를 묶어 다양한 서비스 수준을 정의하는 일을 기획했다고 치자.
이 경우 사용자를 분석해서 군(群)으로 포착하고 정의하지 않는다면 서비스를 만드는 일은 불가능하다. 문제 정의란 바로 우리가 무엇을 만들 것인가에 대해 정의하는 일이라 소프트웨어 개발의 시작과 끝이라고 말할 수도 있다.
<나는 애자일이 싫다> 편에서 인용했던 그림도 도메인 관련 이해해 도움을 준다.
출처: https://www.linkedin.com/in/vaughnvernon/detail/recent-activity/도메인 스토리로 문제(도메인) 구체화하기
문제 정의가 중요한 것을 알겠는데 어떻게 질할 수 있을까? 그에 대한 부분은 DDD 책을 읽는다고 해서 뾰족한 해법이 있는 것은 아니다. 개발자들이 DDD 책에서 활용하는 부분은 대개 빌딩 블록 영역이고 어떻게 구현할 것인가에 해당한다. 마치 디자인 패턴처럼 차용하는 경우들이 대부분이다.
실험적인 단계이지만 우리가 진행중인 도메인 스토리텔링 시도를 통해 ‘어떻게 문제 정의를 할까’를 다뤄본다. 먼저 개념적으로 말하면 아래 그림에서 집합 X의 한 점에 해당하는 문제 묘사가 바로 도메인 스토리에 해당한다.
앞으로 우리회사 동료들이 만들어낼 다양한 도메인 스토리 예제를 공유할 예정이다.
끝으로 <함수형인간 프레임워크>편 에서 썼던 문제의 중요성에 대한 문구를 인용하며 마치겠습니다.
문제는 세상을 보는 창을 제공한다. 무엇을 문제로 삶을 것이냐에 따라 내 시간을 어디에 집중할지 결정할 수 있다. 이때, 문제를 함수라는 시각으로 보면 더욱 단순하게 문제의 핵심에 집중할 수 있다.
