2008/03/09 08:47 Developer
유비쿼터스 랭귀지를 만들때
하나의 도메인 영역을 도메인 전문가 모든 이야기를 해주면서 개발자가 분석을 하면 이상적이다.
하지만, 대부분의 거대한 시스템은 하나의 도메인 전문가 아니라 다수의 전문가가 존재한다.
하나의 프로세스를 여러 팀과 사람이 나누어서 협업을 통해서 업무가 진행되기때문이다.
도메인 전문가들은 각자의 영역에서 최고의 지식을 자랑하고 있지만, 다른 영역의 이야기들은 깊게 알지는 못한다.
심지어 업무의 분리에 의해서 각자의 context에서 사용하는 언어들이 미묘하게 틀린 경우를 발견한다.
전체로 볼때는 하나의 일인데, 왜 다른 용어와 생각을 하는 걸까?
나는 여기서 관점이라는 것을 발견했다. 업무에 따라서 관점이 틀리기때문이다.
관점이 여러개로 나누어질때는 하나의 관점으로 통일을 해서 유비쿼터스 랭귀지를 만들어내는 것이 좋다. context마다 변경이 생길수 있는데, 너무 빠르게 진행을 하면 모호함이 생기는 부작용이 생길수 있다.
이미 관례화되고, 변경이 어려운 것들은 무리하게 비꾸려 하지 말고, 각자의 context의 맞게 천천히 변경을 해가자. 중요한 것은 하나의 관점으로 유비쿼터스 랭귀지를 꾸준히 이야기를 해가는 것이다.
하지만, 대부분의 거대한 시스템은 하나의 도메인 전문가 아니라 다수의 전문가가 존재한다.
하나의 프로세스를 여러 팀과 사람이 나누어서 협업을 통해서 업무가 진행되기때문이다.
도메인 전문가들은 각자의 영역에서 최고의 지식을 자랑하고 있지만, 다른 영역의 이야기들은 깊게 알지는 못한다.
심지어 업무의 분리에 의해서 각자의 context에서 사용하는 언어들이 미묘하게 틀린 경우를 발견한다.
전체로 볼때는 하나의 일인데, 왜 다른 용어와 생각을 하는 걸까?
나는 여기서 관점이라는 것을 발견했다. 업무에 따라서 관점이 틀리기때문이다.
관점이 여러개로 나누어질때는 하나의 관점으로 통일을 해서 유비쿼터스 랭귀지를 만들어내는 것이 좋다. context마다 변경이 생길수 있는데, 너무 빠르게 진행을 하면 모호함이 생기는 부작용이 생길수 있다.
이미 관례화되고, 변경이 어려운 것들은 무리하게 비꾸려 하지 말고, 각자의 context의 맞게 천천히 변경을 해가자. 중요한 것은 하나의 관점으로 유비쿼터스 랭귀지를 꾸준히 이야기를 해가는 것이다.
