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장에 대한 글 에도 언급되었듯이 당연한것을 하지 않는 우를 범하고 있는 자신을 발견하게 됩니다. 여러가지 이유가 있겟습니다만 나 혼자 떠들어서 효과가 있으랴 하는 우려가 가장 크지 않나 싶습니다.
이는 조직문화와도 어느정도 관련이 있어 보입니다.

작은 노력으로 당연함이 정말 당연히 존재 할수 있도록 해야겠다는 생각을 해봅니다.

The Art of war for executives

손자병법!!

우연히 웹서핑중에 발견하였다.
동양의 고전인 손자병법을 외국인의 시각으로 번역한것으로....
executive 를 위한 책이라고 제목을 지었다.
(전략 전술은 executive 에게 만 필요한가?)

앞부분엔 저자의 손자병법에 대한 review 가 있고 뒷부분에 손자병법 전문을 실었다.

전략,전술 어쩌고 하는등의 표현이 조금은 추상적으로 들리기도 한다. 아직까지 손자병법을 읽어 보지 않았다면 영어공부도 할겸 이책으로 접해 보는것은 어떨까.... (얇아서 지하철용으로 딱이다.)

손자병법이 서구사회에서도 대단한 책으로 여겨지는가 보다. 유튜브에 관련 동영상이 많다.

Practices of an agile developer

책이 얇기도 하고 agile 에 대해 제대로 읽어본 책도 없고 해서 선택했다.
agile 의 실천적 방법론에 대해 "악마" 와 "천사"라는 재미있는 대비로 흥미롭게 쓴것 같다. 특히 구어체의 재치있는 표현은 읽는 중간마다 웃음을 자아낸다.
전공 관련 서적을 읽으며 이렇게 웃어본것은 처음일듯....

agile 관련 메일링리스트나 white paper 들을 보면 왠지 복잡할것 같고 어지럽다.
사람에 기반한 방법론이다보니 쉽게 와닿지도 않는다.

이런 생각들을 해본 사람이라면 일독을 권한다.

agile 을 팀에 적용하고자 하는데 구체적 action item 에 대해 고민한다면 팀원들의 필독서로서 손색이 없다.