This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| domain_driven_design:01_crunching_knowledge [2023/08/02 13:20] – [지속적인 학습] ledyx | domain_driven_design:01_crunching_knowledge [2023/08/08 13:11] (current) – removed ledyx | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | = 01 지식 탐구 = | ||
| - | |||
| - | {{tag> | ||
| - | |||
| - | 브레인 스토밍 → 공통 용어 사용 → 모델 정제 → 코드도 함께 발전 | ||
| - | |||
| - | == 효과적인 모델링의 요소 == | ||
| - | |||
| - | - 모델과 구현의 연계 | ||
| - | - 모델을 기반으로 하는 언어 정제 | ||
| - | - 풍부한 지식이 담긴 모델 개발 | ||
| - | - 모델의 정제 | ||
| - | - 브레인스토밍과 경험 | ||
| - | |||
| - | 풍부한 지식이 담긴 모델을 발견하고 | ||
| - | 그러한 모델의 정제를 가능케 하는 것은 | ||
| - | 바로 브레인스토밍과 수차례에 걸친 실험으로 얻는 창의성이다 | ||
| - | |||
| - | == 지식 탐구 == | ||
| - | |||
| - | 도메인 모델링의 주된 목적 : 전체를 이해할 수 있는 간결한 관점 찾기 | ||
| - | ... | ||
| - | 이렇게 뽑아낸 정수는 가장 적절한 것으로 밝혀진 특정 지식을 엄밀하게 표현하는 것이다. | ||
| - | |||
| - | 지식 탐구는 혼자서 하는 활동이 아니다. | ||
| - | 개발자와 도메인 전문가로 구성된 팀은 대체로 개발자가 이끄는 가운데 협업한다. | ||
| - | |||
| - | 폭포수 개발 방식에는 모델을 만들어 내는 데 따른 모든 책임이 분석가에게 있으며, | ||
| - | 이러한 모델은 오로지 업무 전문가가 알려주는 사항에만 근거한다. | ||
| - | |||
| - | 프로그래머가 도메인에 관심이 없다면 | ||
| - | 그 이면에 숨겨진 원리는 알지 못한 채 애플리케이션이 수행해야 할 사항만 습득한다. | ||
| - | 그러한 과정을 거치지 않아도 유용한 소프트웨어를 만들어 낼 수는 있겠지만 | ||
| - | 프로젝트는 기존 기능의 자연스러운 결과로 새로운 강력한 기능이 나타나는 정도의 수준에는 결코 이르지 못한다 | ||
| - | | ||
| - | 훌륭한 프로그래머라면 애초부터 추상화를 시작해서 더욱 많은 일을 해낼 수 있는 모델로 발전시킬 것이다. | ||
| - | 하지만 이 같은 과정이 도메인 전문가와의 협업 없이 기술적인 측면에서만 일어난다면 개념은 초보적인 수준에 머무를 것이다. | ||
| - | 이러한 피상적인 지식은 소프트웨어를 만들어 낼 뿐 | ||
| - | 도메인 전문가의 사고방식과 긴밀하게 연결되지는 않는다 | ||
| - | |||
| - | * 모든 (프로젝트) 구성원이 함께 모델을 만들면 팀 구성원간의 **상호작용** 향상. 이러한 모든 가정을 거쳐 모두가 유능한 지식 탐구자가 된다. 또한 모두가 모델을 만들어 나가므로 모델은 **명료하게 조직화되고 추상화**될 수 있으며, **구현**을 더 용이하게 만들어준다. | ||
| - | * 개발자 : 업무의 중요 원칙들을 배운다. 기능만을 기계적으로 만드는 데 머무르지 않는다. | ||
| - | * 도메인 전문가 : 프로젝트에서 요구하는 개념적 엄밀함(conceptural rigor)을 이해하게 된다. | ||
| - | |||
| - | |||
| - | == 지속적인 학습 == | ||
| - | |||
| - | 소프트웨어를 작성하기 시작할 때, 충분히 알지 못한 상태에서 시작한다. | ||
| - | 해당 프로젝트에서 다룰 지식은 | ||
| - | 단편적이고, | ||
| - | 여러 사람들과 | ||
| - | 문서에 | ||
| - | 흩어져 있으며, | ||
| - | 다른 정보와 섞여 있어 어떤 지식이 정말로 필요한지 알지 못한다. | ||
| - | | ||
| - | 기술적으로 그다지 어려워 보이지 않는 도메인이 사람들을 현혹시키는 경우가 있는데, | ||
| - | 이는 스스로 얼마나 알지 못하는가를 깨닫지 못하는 것이다. | ||
| - | 이러한 무지는 잘못된 가정으로 이어진다. | ||
| - | |||
| - | |||
| - | 지식을 학습한 사람이 조직 개편으로 이동 or 외주 제작 코드 → 지식이 전달되지 않음 | ||
| - | |||
| - | 지속적 학습? 개발자에게는 일반적인 **도메인 모델링 기술(이 책의 내용과 같은)**과 **기술적 지식**이 __모두 향상__된다는 것을 의미한다. 그뿐만 아니라 현재 종사하는 특정 도메인에 관해 진지하게 학습하는 것도 포함된다. | ||
| - | 이처럼 스스로 학습하는 팀원은 Core part를 개발하는 핵심 인력으로 형성된다. | ||
| - | |||
| - | 저자가 배운 것은 PCB 엔지니어가 되는 법이 아니었다. | ||
| - | __PCB 전문가와 대화하고 애플리케이션과 관련된 개념을 이해하며__, | ||
| - | |||
| - | 핵심 모델 요소는 계속 유지됐지만 | ||
| - | 더 중요한 것은 | ||
| - | ... | ||
| - | 모두 똑같이 지식을 얻고 의사소통 체계를 공유하며, | ||
| - | 구현을 거쳐 | ||
| - | 피드백 고리를 완성하는 일을 모두 효과적으로 수행하는 | ||
| - | 지식 탐구 프로세스를 궤도에 올리는 것이다. | ||
| - | |||
| - | |||
| - | == 풍부한 지식이 담긴 설계 == | ||
| - | |||
| - | |||
| - | == 심층 모델 == | ||
| - | |||