[책] 도메인 주도 설계(에릭에반스) -2
링크 - http://yimay.kr/t499o6dfsz
03 모델과 구현의 연계
MODEL-DRIVEN DESIGN(모델 주도의 설계)
- 분석 모델
- 설계와 구분
- 소프트웨어에서 수행할 역할 고려 X
- 업무 도메인 개념만 체계화, 업무 도메인 분석의 결과물
- 이해하기 위한 수단
- 설계와 도메인 모델이 대응 되어야 한다.
- 복잡한 대응은 이해가 어렵고 유지보수가 어렵다.
- 도메인 모델을 설계와 밀접하게 연관시키는 원칙을 강제시, 모델 중 유용한 것을 선택하는 또 하나의 기준이 된다.
- 설계시, 도메인 모델을 있는 그래도 반영, 설계와 모델의 대응을 분명하게 하라.
- 모델에서 사용한 용어들을 설계에서 사용.
- 개발은 모델, 설계 코드를 단일한 활동으로 정제하는 반복적인 과정이 된다.
모델링 패러다임과 도구 지원
- 모델과 구현이 직접적으로 대응
- 객체 설계에서의 진정한 도약은 코드가 모델의 개념을 표현할 때 나온다.
- 언어별 MODEL-DRIVEN DESIGN 을 적용하기 어려운 언어가 있다.
- 설계는 한 번에 나타나는 것이 아니라, 리팩토링과 지식탐구의 과정이 수차례 반복
내부 드러내기 : 왜 모델이 사용자에게 중요한가
- 사용자가 바라보는 것과 시스템이 불일치, 혼란 야기
- MODEL-DRIVEN DESIGN 에서는 (모든 단일 컨텍스트 내에서) 오로지 하나의 모델을 다룰 것을 요구한다.
- 설계가 사용자와 도메인 전문가의 기본적인 관심사를 반영한 모델에 기반을 두면, 설계가 더 큰 범위에 걸쳐 사용자에게 드러날 수 있다.
HANDS-ON MODELER(실천적 모델러)
- 분석과 모델링, 설계, 프로그래밍에 대한 책임을 지나치게 구분하는 것은 MODEL-DRIVEN DESIGN 과 상충한다.
- 모델의 구현과 기술과의 상호작용에 대한 피드백이 간접적이어서는 안된다.
- 코드는 작성한느 사람이 모델에 책임을 느끼지 못하거나 애플리케이션을 대상으로 모델이 동작하게 만드는 법을 모른다면, 그 모델은 소프트웨어와 무관해진다.
- 코드의 변경이 곧 모델의 변경
- 설계자가 구현을 하지 못해 단절이 생기면, 숙련된 설계자의 노하우는 결코 다른 개발자에게 전해지지 못한다.
- 프로그래머가 곧 모델러다.
코드를 변경하는 책임이 있는 모든 이들은 코드를 통해 모델을 표현하는 법을 반드시 배워야한다.
규모가 큰 프로젝트에서는 가장 어렵거나 중요한 의사결정을 내리는 것을 돕는 기술적 측면의 리더가 필요하다.
- 모데인 주도 설계는 모델을 동작하게 만들어 애플리케이션의 문제를 해결한다.