DDD 03장 - 모델과 구현의 연계
본 포스트는 도메인 주도 설계 라는 책을 참조하였습니다. 가능하면 본 책을 직접 보시고 DDD를 이해하는 것을 추천드립니다. http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=12174216
구현에 도움이 되는 모델링
- 간결
- 이해가 쉽고
- 유지보수에 용의
- 초기 분석에 도움
- 설계의 기반
MODEL-DRIVEN DESIGN (모델 주도 설계)
코드와 모델이 긴민하게 연결되면 코드에 의미가 부여되고 모델과 코드가 서로 대응하게 된다.
- 분석모델(analysi model) : 오로지 도메인 분석만을 위한 모델.
- 구현모과 철저하게 분리되어 있기 때문에 유지하는 비용이 너무 비싸다. (구현 시에는 다른 모델링이 요구됨)
- 순수하게 이론적인 내용을 위주로 다루기 때문에 코딩이 시작되면 폐기.
- 중요한 발견은 언제나 설계/구현을 위해 노력하는 가운데 나타난다. (분석 시에는 발견하기 힘들다)
설계가 도메인 모델에 대응해야하며, 설계와 모델 사이에는 단순한 대응으로 이해가 쉬워야한다.
- 수월한 유지보수가 가능
- 소프트웨어의 정확도 향상
- 분석과 설계의 긴밀한 연합으로 인한 도메인전문가와 개발자 간 통찰력 유대
MODEL-DRIVEN DESIGN은 분석모델과 설계를 나누지 않는다
- 분석과 설계라는 두마리 토끼를 잡아야한다.
- 이는 절대로 쉽지 않은 일이다.
소프트웨어 시스템의 일부를 설계할 때는 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응을 분명하게하라. 또한 모델을 재검토해서 더욱 자연스럽게 소프트웨어로 구현될 수 있게 수정하라. 도메인에 과한 더욱 심층적인 통찰력을 반영하려 할 때도 마찬가지이다. 이렇듯 견고한 UBIQUITOUS LANGUAGE를 지원하는 것과 더불어 분석과 설계의 두 가지 측면을 충분히 만족하는 단 하나의 모델을 만들어내야 한다.
모델로부터 설계와 기본적인 책임할당에 사용한 용어를 도출하라. 코드를 작성할 때 그러한 용어를 사용하면 코드가 모델을 표현한 것이 되고, 코드의 변경이 곧 모델의 변경으로 이어질 수 있다. 그 효과는 프로젝트의 나머지 활동에도 퍼져나가야 한다.
구현을 모델과 그대로 묶으려면 보통 객체지향 프로그래밍과 같은 모델링 패러다임을 지원하는 소프트웨어 개발 도구와 언어가 필요하다
모델링 패러다임 도구 지원
// TODO 그림 3-1 삽입
이 부분은 잘 모르겠음. - 다시 한 번 읽어보자.
내부 드러내기: 왜 모델이 사용자에게 중요한가
설계가 사용자(UI, UX)와 도메인 전문가의 기본적인 관심사를 반영하는 모델에 기반을 두면 설계의 골격이 다른 설계 접근법에 비해 더 큰 범위에 걸쳐 사용자에게 드러날 수 있다. 모델이 드러나면 사용자가 소프트웨의 잠재력을 좀 더 많이 접하게 되어 일관성 있고 예상 가능한 행위가 나타날 것이다.
HANDS-ON MODELER (실천적 모델러)
분석, 모델링, 설계, 프로그래밍에 대한 책임을 지나치게 구분하는 것(폭포수 모델)은 MODEL-DRIVEN DESIGN 과 상충한다.
기존 방식 모델링의 2가지 단점
- 모델의 의도 중 일부가 이관되면서 사라짐. 세부사항은 일반적인 토의 내용에서는 발견되지 않음.
- 모델의 구현과 기술과의 상호 작용에 대한 피드백이 간접적일 수 밖에 없다. 모델링과 구현을 격리 시키므로
코드를 작성하는 사람이 모델에 책임을 느끼지 못하거나 애플리케이션을 대상으로 모델이 동작하게 만드는 법을 모른다면 그 모델은 소프트웨어와 무관해진다. 코드의 변경이 곧 모델의 변경이라는 점을 개발자가 인식하지 못하면 리팩터링은 모델을 강화하기보다는 약화시킬 것이다. 한편으로 모델러가 구현 프로세스와 분리돼 있을 경우, 구현상의 제약조건을 감안하는 능력을 결코 갖추지 못하거나 금방 잃어버릴 것이다. 모델이 효과적인 구현을 뒷받침하고 핵심 도메인 지식을 추상화한다는 MODEL-DRIVEN DESIGN의 기본적인 제약조건은 절반쯤 사라지고, 결과로 나타나는 모델은 실용적이지 못할 것이다. 결국 MODEL-DRIVEN DESIGN을 코드로 만드는 과정의 미묘한 사항들은 협업을 통해 알 수 있는데, 설계자가 구현을 하지 못해 개발자와 업무의 단절이 생기면 숙련된 설계자의 지식과 솜씨는 결코 다른 개발자에게 전해지지 못할 것이다.
모델에 기여하는 모든 기술자는 프로젝트 내에서 수행하는 일차적 역할과는 상관없이 코드를 접하는 데 어느 정도 시간을 투자해야만 한다. 코드를 변경하는 책임이 있는 모든 이들은 코드를 통해 모델을 표현하는 법을 반드시 배워야 한다. 모든 개발자는 모델에 관한 일정 수준의 토의에 깊이 관연해야 하고 도메인 전문가와도 접촉해야 한다. 다른 방식으로 모델에 기여하는 사람들은 의식적으로 코드를 접하는 사람들과 UBIQUITOUS LANGUAGE를 토대로 모델의 아이디어를 나누는 데 적극 참여해야 한다.
