BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
200,270 Visitors up to today!
Today 26 hit, Yesterday 50 hit
daisy rss
2009.11.10 08:47

지금의 현실...
On a project without a common language, developers have to translate for domain experts.

The effort of translation prevents the interplay of knowledge and ideas that lead to deep model insights.

DDD의 이상...
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.


왜 우리는 누구나 당연하다고 생각하는 것들을 해 오지 않았을까요?
아주 당연한 것들이 지켜지지 않는 것이, 아주 어려워보이는 것이 지켜지지 않고 있을 때 보다 바로잡기가 더 어렵습니다. 눈에 보이지 않은 수많은 거대한 장애물들이 있기 때문입니다.

우리의 개인적인 경험으로 볼 때 저자의 도전은 무모한 것처럼 보이기도 합니다.
무모하지만 꼭 해야 할 일이라고 생각합니다. 장애물 들이 하나씩 하나씩 치워질 때 마다 당연한 것의 자리를 차지하는 당연한 것들이 늘어갈 것입니다. 


Key Points
도메인모델을 기반으로 하는 하나의 유비쿼터스 언어

Play with the model as you talk about the system. Describe scenarios out loud using the elements and interactions of the model, combining concepts in ways allowed by the model. Find easier ways to say what you need to say, and then take those new ideas back down to the diagrams and code.



프로그래밍은 설계입니다. 
우리는 항상 생각하고 있고, 항상 설계하고 있습니다.
그것이 그래픽(UML)으로 표현되느냐, 텍스트(프로그래밍 언어)로 표현되느냐의 차이는 있을 수 있습니다. 
프로그래밍하면서 '저는 설계는 않고 구현만 하는데요'라고 말하는 것은 앞뒤가 맞지 않습니다.

The code can serve as a repository of the details of the design.

다른 관점으로 이 말을 곱십어 보면, 항상 프로그래밍 언어가 텍스트일 필요가 없다는 생각도 할 수 있습니다.
다음 세대의 프로그래밍 언어가 그래픽 표현(UML)이 되지 말라는 법은 없다는 것입니다.



RSMer's Page

이 장에서는 모델링 결과를 표현하는 관점 만을 부각해서 모델링 언어나 다이어그램이나 코드를 다루고 있습니다. 

UML에는 이것이 실제로 사용될까? 라고 생각할 만한 모델요소들이 많이 있습니다. 그래서 일부 과격한 사람들은 다 필요 없고 아주 조금 이것만 있으면 된다라고 주장하기도 합니다.
이는 모델링을 위해서 필요로 하는 것과 모델링의 결과를 표현하기 위해서 필요로 하는 것을 구분하지 못하기 때문에 하는 주장입니다.


모델링은 다량의 정보를 통합적인 관점과 분석적인 관점으로 다루어야 하는 고난이도의 복잡한 작업입니다. 텍스트(프로그래밍 언어)만을 사용하거나 한 두 가지 관점 만을 지원하는 도구로는 제대로된 모델을 만들 수 없습니다. 

복잡한 대상을 분석하고 종합한 결과는 E = mc2과 같이 매우 단순하게 표현될 수 있습니다. 결과가 단순하다고 해서 생각의 과정 또한 단순하지는 않습니다. 

UML에는 다양한 관점으로 모델링 할 수 있도록 다양한 모델요소들을 지원합니다. UML의 문제는 UML이 방법론이 아니라 모델링 언어이기 때문에 언제 어떻게 사용해야 하는지를 명시적으로 설명하지 않는다는 것입니다. 

행위형식화는 모델링에 요구되는 종합적 사고와 분석적 사고를 동시에 지원하는 도구입니다. 행위형식화는 모델링 과정에서 UML 모델요소들을 적재적소에 사용합니다.
저작자 표시 비영리 변경 금지
신고
엄성권 | 2009.11.11 09:17 신고 | PERMALINK | EDIT/DEL | REPLY
"UML에는 이것이 실제로 사용될까? 라고 생각할 만한 모델요소들이 많이 있습니다. 그래서 일부 과격한 사람들은 다 필요 없고 아주 조금 이것만 있으면 된다라고 주장하기도 합니다.
이는 모델링을 위해서 필요로 하는 것과 모델링의 결과를 표현하기 위해서 필요로 하는 것을 구분하지 못하기 때문에 하는 주장입니다"
==> 조금 만 더 구체적으로 설명부탁드립니다. 결과물는 적은량의 모델링 다이어그램일수 있으나 그 결과를 얻기까지 과정상에 많은 다이어그램들이 필요하다는 뜻인가요.
Justine | 2009.11.11 11:52 신고 | PERMALINK | EDIT/DEL
그렇습니다.

다이어그램은 커뮤니케이션을 위해서도 사용될 수 있고, 모델을 표현하기 위해서도 사용될 수 있습니다.
또한 다양한 관점을 가지고 복잡한 것을 이해해가는데도 사용할 수 있습니다.

제대로된 모델을 만드는데 집중하는 것이 아니라 문서화하는데 집중하기 때문에 다양한 다이어그램들에 대한 무용론이 등장하는 것입니다.
잘못된 모델에 대한 잘못된 표현들이 많아봐야 뭐하겠습니까? 차라리 한 장이라도 제대로된 것이 있는게 더 낫겠지요.
최상호 | 2009.11.11 22:46 신고 | PERMALINK | EDIT/DEL | REPLY
정말 다시 한 번 커뮤니케이션의 중요함을 이번 장을 보면서 느낍니다. 또한,커뮤니케이션은 서로 상대방을 존중함으로써 시작한다고 생각합니다. 개발자는 domain expert를 해당하는 그 '분야의 전문가'로 인정해야 하고 domain expert도 개발자를 '갑'의 입장에서 '을'대하듯 하는게 아니라 협력자로 대할 때에 비로소 저자의 얘기대로 커뮤니케이션이 잘 이루어지지 않나 싶습니다.

행위형식화에서도 요구정보 모델링을 할 때 끊임없이 고객(도메인 전문가)과 대화를 하며 진행합니다. 고객들을 프로젝트 착수보고회 때만 만나는 존재가 아니라 지속적으로 함께 작업을 하는 동료로 대하는 것이죠.
결국 요구정보 모델링에 의한 산출물은 개발자 혼자가 아닌 도메인 전문가와의 협업에 의한 결과물인 거죠. 교육 때도 새삼 '고객' 또는 '도메인 전문가' 라는 단어가 계속 귀에 맴돌았는데 이 책에서도 동일하게 같은 얘기를 하는군요... 흥미로웠습니다.
Name
Password
Homepage
Secret

티스토리 툴바