DDD Chapter 2 - communication and the Use of Language
2장의 핵심은 communication 입니다.
요구분석, 설계, 구현 모든 단계에 있어 communication 을함에 있어 비효율, 혼선 등을 제거하기위해 계속해서 노력해야 함을 피력하고 있습니다.
특히 domain expert, developer 그리고 고객이 서로 다른 language 를 사용함으로 인한 심각한 문제가 발생할수 있음을 지적합니다. 여기서 language 란 단순히 통일되지 못한 용어만을 의미하지 않습니다. domain expert 는 업무 domain 적 사상으로 이야기 하고 developer 는 기술적 관점에서 이야기함으로 인해 둘사이의 혼선(translation 을 함으로 인한 낭비 및 혼선)이 가중됨을 지적합니다.
이에 대한 해결책으로 공통의 언어( ubiquitous language)를 사용할것을 이야기 하고 있습니다.
가장 기본적으로 같은 용어를 사용해야 하고 같은 관점에서 바라보고 논의 해야 합니다.
이렇게 되기 까지 많은 혼선과 시간이 소요되겠지만 피하지 말고 계속 노력할것을 요구합니다.
여기서 언어란 용어 혹은 문서 만을 의미 하지 않습니다. diagram, writing, 문서 및 코드 전부분에 ubiquitous language 가 녹아 들어가야 한다고 말합니다.
"Use the model as the backbone of a language. commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech."
흔히들 model 하면 diagram(UML 같은)을 떠올림니다. 저자는 Model 이 곧 digram은 아니라고 합니다. 전체에 대한 overview 를 이해 함에 있어 diagram 만으로는 그 표현에 제약이 있습니다.
따라서 Model 을 기술함에 있어 diagram 뿐아니라 description, code 등으로 전반적 살을 붙혀 나가야 함을 말하고 있습니다.
XP 에서는 code 가 시스템을 설명할수 있게끔 transparent 한 code 를 해야 한다고 합니다. 하지만 code 만으로 모든것을 전달할수는 없습니다. 시스템에 대한 이해를 위해 code 를 봐야 한다면 이만저만한 낭비가 아닐수 없습니다. 또한 모든 이해관계자들이 code 를 이해할수 있는것도 아니지요.
code, 주석, 별도의 문서가 총체적으로 시스템을 이해하는 수단이 되어야 합니다.
이를 위해 여러가지 귀찮은 점도 있습니다. 가장 대두되는것이 document 가 code 의 진화 속도를 못따라 가는 문제 입니다. 또한 code, document , 주석들이 사용하는 용어의 gap 이 문제가 되기도 합니다. 용어의 gap 은 위에서 말한 공통의 언어를 찾아가는 과정에서 문서, 주석 그리고 code 를 업데이트 해나가야 할것입니다.
저자는 modeling 함에 있어 보통 모든 내용을 diagram 으로 표현해야 할것 같은 강박관념이 오히려 본질을 전달하는데 방해가 된다는것을 지적하고 있습니다.
(개인적으로도 UML 을 처음 도입할때 약 60여개의 class 및 모든 Usecase 를 그리느라 시간낭비 한적이 있습니다. ^^;;)
diagram 은 핵심만을 간략화하여 그리고 description 으로 새부적인것을 설명함이 전체를 이해하는데 더 효과적이라고 말하고 있습니다.
다이어그램이라고 해서 꼭 UML 만을 고집할 필요는 없습니다. 다른 형태의 그림으로도 UML 보다 더 효과적으로 전달할수 있다면 UML 을 고집하지 않는것이 낳을것입니다.
마지막으로 현남님의 2장에 대한 글 에도 언급되었듯이 당연한것을 하지 않는 우를 범하고 있는 자신을 발견하게 됩니다. 여러가지 이유가 있겟습니다만 나 혼자 떠들어서 효과가 있으랴 하는 우려가 가장 크지 않나 싶습니다.
이는 조직문화와도 어느정도 관련이 있어 보입니다.
작은 노력으로 당연함이 정말 당연히 존재 할수 있도록 해야겠다는 생각을 해봅니다.
요구분석, 설계, 구현 모든 단계에 있어 communication 을함에 있어 비효율, 혼선 등을 제거하기위해 계속해서 노력해야 함을 피력하고 있습니다.
특히 domain expert, developer 그리고 고객이 서로 다른 language 를 사용함으로 인한 심각한 문제가 발생할수 있음을 지적합니다. 여기서 language 란 단순히 통일되지 못한 용어만을 의미하지 않습니다. domain expert 는 업무 domain 적 사상으로 이야기 하고 developer 는 기술적 관점에서 이야기함으로 인해 둘사이의 혼선(translation 을 함으로 인한 낭비 및 혼선)이 가중됨을 지적합니다.
이에 대한 해결책으로 공통의 언어( ubiquitous language)를 사용할것을 이야기 하고 있습니다.
가장 기본적으로 같은 용어를 사용해야 하고 같은 관점에서 바라보고 논의 해야 합니다.
이렇게 되기 까지 많은 혼선과 시간이 소요되겠지만 피하지 말고 계속 노력할것을 요구합니다.
여기서 언어란 용어 혹은 문서 만을 의미 하지 않습니다. diagram, writing, 문서 및 코드 전부분에 ubiquitous language 가 녹아 들어가야 한다고 말합니다.
"Use the model as the backbone of a language. commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech."
흔히들 model 하면 diagram(UML 같은)을 떠올림니다. 저자는 Model 이 곧 digram은 아니라고 합니다. 전체에 대한 overview 를 이해 함에 있어 diagram 만으로는 그 표현에 제약이 있습니다.
따라서 Model 을 기술함에 있어 diagram 뿐아니라 description, code 등으로 전반적 살을 붙혀 나가야 함을 말하고 있습니다.
XP 에서는 code 가 시스템을 설명할수 있게끔 transparent 한 code 를 해야 한다고 합니다. 하지만 code 만으로 모든것을 전달할수는 없습니다. 시스템에 대한 이해를 위해 code 를 봐야 한다면 이만저만한 낭비가 아닐수 없습니다. 또한 모든 이해관계자들이 code 를 이해할수 있는것도 아니지요.
code, 주석, 별도의 문서가 총체적으로 시스템을 이해하는 수단이 되어야 합니다.
이를 위해 여러가지 귀찮은 점도 있습니다. 가장 대두되는것이 document 가 code 의 진화 속도를 못따라 가는 문제 입니다. 또한 code, document , 주석들이 사용하는 용어의 gap 이 문제가 되기도 합니다. 용어의 gap 은 위에서 말한 공통의 언어를 찾아가는 과정에서 문서, 주석 그리고 code 를 업데이트 해나가야 할것입니다.
저자는 modeling 함에 있어 보통 모든 내용을 diagram 으로 표현해야 할것 같은 강박관념이 오히려 본질을 전달하는데 방해가 된다는것을 지적하고 있습니다.
(개인적으로도 UML 을 처음 도입할때 약 60여개의 class 및 모든 Usecase 를 그리느라 시간낭비 한적이 있습니다. ^^;;)
diagram 은 핵심만을 간략화하여 그리고 description 으로 새부적인것을 설명함이 전체를 이해하는데 더 효과적이라고 말하고 있습니다.
다이어그램이라고 해서 꼭 UML 만을 고집할 필요는 없습니다. 다른 형태의 그림으로도 UML 보다 더 효과적으로 전달할수 있다면 UML 을 고집하지 않는것이 낳을것입니다.
마지막으로 현남님의 2장에 대한 글 에도 언급되었듯이 당연한것을 하지 않는 우를 범하고 있는 자신을 발견하게 됩니다. 여러가지 이유가 있겟습니다만 나 혼자 떠들어서 효과가 있으랴 하는 우려가 가장 크지 않나 싶습니다.
이는 조직문화와도 어느정도 관련이 있어 보입니다.
작은 노력으로 당연함이 정말 당연히 존재 할수 있도록 해야겠다는 생각을 해봅니다.
댓글
어쩌면 사람들은 '대화, 회의, 말, 어휘'처럼 가장 쉽고 강력한 의사소통을 내버려두고 시각적인 것에만 집중하고 있는지도 모르겠습니다.