[책] 도메인 주도 설계(에릭에반스) -1
Jun 03, 2017/Jun 04, 2017
제 1부 동작하는 도메인 만들기
- 도메인과 모데인 로직에 집중
- 설계는 모델을 기반으로
- 모델은 문제 해결을 위한 추상화, 세부사항 x
- 지식의 추상화 - 도메인 모델
01장__지식탐구
- 도메인 전문가와 대화를 통해서 지식을 습득해 가고 그것을 모델, 다이어그램으로 정리
- 초기 프로토타입 생성
- 지속적으로 모델을 발전 시키고 불필요한 개념 제거
- 과거의 폭포수 모델 : 지식의 방향이 한방향으로 흐른다.
- 훌륭한 프로그래머 : 추상화를 통한 모델 발전, 도메인 전문가와의 협의 필요
- 모델은 결코 완별해질수 없으며, 다만 계속 발전해나갈뿐.
- 모델은 도메인을 이해하는데 실용적이고 유용해야한다.
- 도메인 전문가가 더 많이 배워 애플리케이션의 목표를 분명하게 만든다.
- 정책이랑 Strategy패턴의 또다른 이름이다.
- 명시적으로 드러나고 다른 구현과 분리되도록 하자. (ex. OverbookingPolicy 클래스)
02장__의사소통과 언어 사용
- 도메인 모델은 프로젝트를 위한 공통언어의 핵심
- 의사소통 = UML + 문서 + 코드 + 테스트
- Ubiquitous Language(보편언어)
- 공통언어를 사용해야한다.
- 도메인 전문가 : 도메인언어 , 기술자 : 도메인을 이해한 자신들만의 언어 => 분열
- 쓰는 용어가 코드가 된다.
- 번역은 의사소통을 무디게 하고 지식탐구를 빈약하게 만든다.
- 클래스와 주요 연산의 이름이 있고, 패턴의 이름이 들어간다.
- 모델의 관계는 모든 언어에 내재된 결합 규칙이 된다.
- 도메인전문가, 기술자가 공통언어로 의사소통해야 한다.
- 모델을 언어의 근간으로 사용하라.
- 공통언어 => 모델 => 리팩토링(클래스, 메소드, 모듈)
- Ubiquitous Language 의 변화가 곧 모델의 변화.
- 크게 소리내어 모델링하기
- 모델을 정제하는 가장 좋은 방법은 다양한 구성요소들을 큰소리로 말하는 것.
- 시스템에 관한 이야기를 주고 받을때 모델을사용하라
- 한팀, 한언어
- 모델의 핵심은 도메인 전문가의 관심을 끌어야 한다.
- 수준높은 도메인 전문가도 해당모델을 이해하지 못한다면 모델이 뭔가 잘못된것.
- 도메인 전문가과 개발자 사이에 언어절 분열이 일어나서는 안된다.
- 대화, 논의, 코드까지 공유된 도메인 모델에서 비롯된 동일한 언어를 기반으로 해야한다.
- 문서와 다이어그램
- 형식에 얽매이지 않는 UML 다이어그램
- UML다이어그램은 모델 내 객체의 행위와 모델의 개념과 의미를 전달할 수 없다.
- 필수적인 부분만 다이어그램으로 구성
- 설계의 세부사항은 코드에 담긴다.
- 구현은 설계를 지태하는 모델을 드러내야 한다.
- 모델은 다이어그램이 아니다. 모델을 전달하는 목적.
- 코드는 설계의 세부사항의 저장소 역할
- 글로 쓴 설계 문서
- 문서는 코드와 말을 보완하는 역할을 해야한다.
- 코드자체만으로는 양에 의해 압도 될수 있다.
- 구두와 화이트보드는 일시적, 국지적
- 문서는 코드가 이미 잘 하고 있는 것을 하려고 해서는 안된다. (코드는 세부사항)
- 글로 쓴 문서는 코드와 논의를 보완해야한다.
- 문서는 유효한 상태를 유지, 최신내용을 담고 있어야 한다.
- 가장 큰 가치는 모델의 개념 설명, 코드의 세부사항 파악, 모델의 의도 파악
- 문서는 프로젝트 활동과 관련을 맺고 있어야 한다. (문서가 공통언어와 상호작용을 하는지)
- 문서가 중요하다고 느껴지지 않으면 최신상태로 유지 하지 않게 된다.
- 문서를 최소한 유지, 코드와 대화를 보완하는데 집중
- 실행 가능한 기반
- 코드가 전달하는 메시지가 정확하는 보장은 없다.
- 올바른 실행뿐만 아니라, 올바른 의미를 전달하는 코드의 작성은 엄청난 노력이 필요
- 코드는 동일한 언어를 기반으로 해야한다.
- 설명을 위한 모델
- 하나의 모델이 구현, 설계, 의사소통의 기초가 되야한다.
- 설명을 위한 모델(전달력 높은 의사소통 방식)과 기술적 모델(기능 수행을 위한 최소한의 범위)