브레인 스토밍 → 공통 용어 사용 → 모델 정제 → 코드도 함께 발전
풍부한 지식이 담긴 모델을 발견하고 그러한 모델의 정제를 가능케 하는 것은 바로 브레인스토밍과 수차례에 걸친 실험으로 얻는 창의성이다
도메인 모델링의 주된 목적 : 전체를 이해할 수 있는 간결한 관점 찾기 ... 이렇게 뽑아낸 정수는 가장 적절한 것으로 밝혀진 특정 지식을 엄밀하게 표현하는 것이다.
지식 탐구는 혼자서 하는 활동이 아니다. 개발자와 도메인 전문가로 구성된 팀은 대체로 개발자가 이끄는 가운데 협업한다.
폭포수 개발 방식에는 모델을 만들어 내는 데 따른 모든 책임이 분석가에게 있으며, 이러한 모델은 오로지 업무 전문가가 알려주는 사항에만 근거한다.
프로그래머가 도메인에 관심이 없다면 그 이면에 숨겨진 원리는 알지 못한 채 애플리케이션이 수행해야 할 사항만 습득한다. 그러한 과정을 거치지 않아도 유용한 소프트웨어를 만들어 낼 수는 있겠지만 프로젝트는 기존 기능의 자연스러운 결과로 새로운 강력한 기능이 나타나는 정도의 수준에는 결코 이르지 못한다 훌륭한 프로그래머라면 애초부터 추상화를 시작해서 더욱 많은 일을 해낼 수 있는 모델로 발전시킬 것이다. 하지만 이 같은 과정이 도메인 전문가와의 협업 없이 기술적인 측면에서만 일어난다면 개념은 초보적인 수준에 머무를 것이다. 이러한 피상적인 지식은 소프트웨어를 만들어 낼 뿐 도메인 전문가의 사고방식과 긴밀하게 연결되지는 않는다
소프트웨어를 작성하기 시작할 때, 충분히 알지 못한 상태에서 시작한다. 해당 프로젝트에서 다룰 지식은 단편적이고, 여러 사람들과 문서에 흩어져 있으며, 다른 정보와 섞여 있어 어떤 지식이 정말로 필요한지 알지 못한다. 기술적으로 그다지 어려워 보이지 않는 도메인이 사람들을 현혹시키는 경우가 있는데, 이는 스스로 얼마나 알지 못하는가를 깨닫지 못하는 것이다. 이러한 무지는 잘못된 가정으로 이어진다.
지식을 학습한 사람이 조직 개편으로 이동 or 외주 제작 코드 → 지식이 전달되지 않음
지속적 학습? 개발자에게는 일반적인 도메인 모델링 기술(이 책의 내용과 같은)과 기술적 지식이 모두 향상된다는 것을 의미한다. 그뿐만 아니라 현재 종사하는 특정 도메인에 관해 진지하게 학습하는 것도 포함된다.
이처럼 스스로 학습하는 팀원은 Core part를 개발하는 핵심 인력으로 형성된다.
저자가 배운 것은 PCB 엔지니어가 되는 법이 아니었다.
PCB 전문가와 대화하고 애플리케이션과 관련된 개념을 이해하며, 애플리케이션이 정상적으로 동작하는지 점검하는 것이었다.
핵심 모델 요소는 계속 유지됐지만 더 중요한 것은 ... 모두 똑같이 지식을 얻고 의사소통 체계를 공유하며, 구현을 거쳐 피드백 고리를 완성하는 일을 모두 효과적으로 수행하는 지식 탐구 프로세스를 궤도에 올리는 것이다.
업무활동/규칙 간의 모순되는 부분을 찾아내어
명확하게 하고, 구체화하며, 조정하는 것은
개발자와 도메인 전문가와의 긴밀한 협업하에서 진행되는 지식 탐구를 통해 이뤄진다
깊은 지식 탐구 → 모순되거나 감춰진 개념을 찾아 구체화하기
하지만 저자는 도메인의 모든 세부사항에 정교한 설계를 적용하라고 권하는 것이 아니다. → 디스틸레이션! 중요한 것에만 집중!
유용한 모델은 겉으로 드러나 있는 경우가 거의 없다
도메인과 요구사항 이해 → 문제의 핵심을 관통하는 포착하기 힘든 추상화