- 다이어그램은 벽 크기만큼이나 압도적이어서 이모델에는 분명 상당한 지식이 포함돼 있었다. ...
학습 방향을 잡기가 힘들었는데, 이건 마친 웹을 무작위로 돌아다니는 것과 흡사했다.
하지만 더욱 난감했던 점은 이렇게 학습한 내용이 애플리케이션 코드와 설계에 어떠한 통찰력도 줄 수 없다는 점이었다. ...
데이터 저장소와 같은 클래스명과 속성명을 일부 사용하긴 했지만 그 설계는 기존 모델 또는 어떠한 모델에도 근거하지 않은 것이었다.
프로젝트에 도메인 모델은 있었지만 동작하는 소프트웨어를 개발하는 데 직접적으로 도움을 주지 않는 한 종이에 기록된 모델이 무슨 의미가 있겠는가? - p45 ~ 46 - 도메인 주도 설계에서는 초기 분석 단계에 도움이 될 뿐 아니라 설계의 기반이 되는 모델이 필요하다 - p46
- 설계 혹은 설계의 주된 부분이 도메인 모델과 대응하지 않는다면 그 모델은 그다지 가치가 없으며 SW의 정확함도 의심스러워진다. 동시에 모델과 설계 기능 사이의 복잡한 대응은 이해하기 힘들고, 실제로 설계가 변경되면 유지보수가 불가능해진다. 분석과 설계가 치명적으로 동떨어지고, 그에 따라 각자의 활동에서 얻은 통찰력이 서로에게 전해지지 않는다. (그래서 분석부터 설계/구현까지 연결되는 흐르을 가져야 한다) - p49
- 분석은 도메인의 근본적인 개념을 알기 쉽고 표현력 있는 방식으로 포착해야 한다 - p49
'DDD' 카테고리의 다른 글
05장_소프트웨어에서 표현되는 모델(Entity, VO, Service, Module) (0) | 2021.10.05 |
---|---|
04장_도메인의 격리(Layered Architecture중 Domain) (0) | 2021.10.05 |
02장_의사소통과 언어사용(Ubiquitous Language 보편언어) (0) | 2021.10.01 |
00_서문 (0) | 2021.10.01 |
01장_지식탐구 (0) | 2021.09.30 |