일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- DDD
- Linux
- docker
- spark
- hibernate
- hdfs
- Clean Code
- hadoop
- Gradle
- Angular2
- 스프링 배치
- 제주
- elasticsearch
- apache storm
- Domain Driven Design
- intellij
- Hbase
- nginx
- Storm
- elastic search
- Spring Batch
- scala
- 엘라스틱서치
- 도메인주도설계
- Spring XD
- SBT
- Java
- Spring Boot
- design pattern
- Spring
- Today
- Total
욱'S 노트
DDD - 의사소통과 언어 사용 본문
도메인 모델은 공통언어의 핵심이자 도메인에 대한 통찰력을 반영하는 용어와 관계로 표현된다. 모델기반의 의사소통으로 꼭 UML을 사용해야 하는 것은 아니다. 어떠한 의사소통 수단을 사용해도 무방하며 형식에 얽매이지않는 다이어그램이나 텍스트문서도 가능하다. 또한 코드 자체를 통할 수도 있다.
UBIQUITOUS LANGUAGE
도메인 전문가와 개발자가 각자 자기의 언어를 사용하면 안된다. 이는 정보 흐름의 병목으로 이어지며 그들이 번역하는 바도 정확하지 않다.
유비쿼터스 언어를 사용하지 않을때 발생하는 문제는 다음과 같다.
- 각자의 언어로 얘기를 하기 때문에 토론이 되지 않는다.
- 용어와 코드의 정보가 단절된다.
- 번역은 의사소통을 무디게 하고 지식탐구를 빈약하게 만든다.
브레인스토밍과 실험 중 언어에 공백이 발견되면 이것은 즉 도메인 모델에 반영되어야 하는 것을 의미한다. 또한 표현이 부자연스럽거나 불완전할 경우 도메인 모델을 변경해야 한다. 유비쿼터스 언어의 변화가 곧 모델의 변화이다.
좋은 언어의 예
Routing 서비스에 출발지, 도착시간을 이력하면 화물이 멈춰야 할 지점을 찾고 데이터베이스에 저장한다. (모호하고 기술적임) ->
Routing 서비스는 Route Specification을 만족하는 Itenrary를 찾는다.
업무분석가가 상세 설계를 이해못하고 개발자가 모델을 이해못한다면 잘못된 것이다.
문서와 다이어그램
모델은 다이어그램이 아니다. UML 다이어그램은 두가지 측면에서 불만족스럽다. 모델이 나타내는 개념의 의미와 모델 내 객체의 행위. 이러한 사항들은 텍스트로 보충하라. 다이어그램은 목적은 모델을 잘 전달하고 설명하는데 있다.
문서는 항상 유효한 상태를 유지하고 최신 내용을 담고 있어야 한다. -> (밥 아저씨는 문서는 없어져야 한다고도 말했다. 켄트백은 어떤 프로젝트를 가도 믿을만한 설계 문서는 사용자매뉴얼밖에 없었다고 했다.) 코드를 문서처럼 명확하게 작성하라. 코드가 이미 잘하고 있는 것을 하지마라. 문서는 최소한으로 유지하라. 유효하지 않는 문서는 없느니만 못하다.
'Methdology > Domain Driven Design' 카테고리의 다른 글
DDD - 도메인의 격리 (0) | 2016.01.27 |
---|---|
DDD - 모델 주도 설계 (0) | 2016.01.27 |
DDD - 지식 탐구 (0) | 2016.01.27 |
DDD - 도메인 모델이란? (0) | 2016.01.27 |
DDD - Model Driven Design (0) | 2015.04.16 |