일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- spark
- DDD
- SBT
- elastic search
- nginx
- Spring XD
- docker
- Gradle
- Linux
- Hbase
- 제주
- intellij
- hibernate
- Spring Batch
- 도메인주도설계
- Spring
- 엘라스틱서치
- hadoop
- Angular2
- hdfs
- Storm
- Spring Boot
- scala
- apache storm
- Domain Driven Design
- 스프링 배치
- Clean Code
- design pattern
- Java
- elasticsearch
- Today
- Total
욱'S 노트
DDD - 시작하기 본문
비행기 운항 제어 시스템을 고려해보자. 이 시스템의 목적은 비행기가 운항중인 경로를 추적하고, 잘 진행되고 있는지 모니터링하는 것이다. 어디서부터 시작해야 되나? 도메인을 이해하는 것부터 시작하자. 항공운항관리사가 도메인을 가장 잘 아는 스페셜리스트이다. 하지만 그는 시스템 설계자도 아니고, 소프트웨어 스페셜리스트도 아니다.
항공운항관리사는 도메인에 대한 넓은 지식을 가지고 있다. 하지만 모델을 구축하기 위해 우리는 핵심 정보를 추출하고 일반화 할 필요가 있다. 전문가와 대화를 하다보면 착륙, 충돌 위등 엄청난 양의 정보가 있다는 것을 알 수 있다. 그러나 어디선가 모델링을 시작해야 한다. 항공운항관리사와 당신은 각 비행기는 출발지와 도착지를 가지고 있다는 것에 동의했다. 간단하게 다음과 같이 그릴 수 있다.
그리고 항공운항관리사가 다시 부연설명을 했다. 각각의 비행기는 전체 경로를 할당받는다고 말했다. 흥미로운 단어를 들었다. 경로. 경로는 비행에서 매우 중요한 요소이다. 모델은 아래와 같이 변경된다.
다시 항공운항관리사와 대화를 계속하니 경로는 다양한 지점의 집합이라는 것을 알게 되었다. 더 이상 출발지와 도착지를 구분할 필요없이 지점의 일련의 집합이 경로라고 판단하게 되었다.
해당 그림을 보고 항공운항관리사는 지점은 단순한 위도와 경도이지 고도는 고려할 필요가 없다고 했다. 그래서 모델은 다음과 같이 수정되었다.
전문가와 대화를 나눌수록 지식은 교환된다. 질문을 하기 시작하면 그들은 대답을 할 것이다. 당신과 전문가는 도메인 모델을 그리기 시작했다. 이것은 디자인의 중요한 부분이다. 떄로는 많은 시간이 걸릴 것이다. 소프트웨어 아키텍트는 도메인 전문가로부터 정확한 지식을 얻을 수 있고, 유용한 형식으로 변경할 수 있다. 커뮤니케이션은 단방향이면 안된다. 피드백은 더 좋은 모델을 만들수 있고, 더 명확하고 정확하고 도메인을 이해할 수 있다.
'Methdology > Domain Driven Design' 카테고리의 다른 글
DDD - 지식 탐구 (0) | 2016.01.27 |
---|---|
DDD - 도메인 모델이란? (0) | 2016.01.27 |
DDD - Model Driven Design (0) | 2015.04.16 |
DDD - Ubiquitous Language (0) | 2015.02.09 |
DDD - Domin Driven Design이란? (0) | 2015.02.04 |