1부 동작하는 도메인 모델 만들기
사용자가 프로그램을 사용하는 대상 영역이 바로 도메인.
모델 이란 뭐지?
설계시 원하는 View 의 형태로 보여지는 도메인의 필요한 부분들을 추상화 시킨 것
도메인 주도 설계에서의 모델의 유용성.
도메인 주도 설계에서는 아래의 세 가지 기본적인 쓰임새에 따라 모델을 선택한다.
1. 모델과 핵심 설계는 서로 영향을 주며 구체화된다.
2. 모델은 모든 팀 구성원이 사용하는 언어의 중추다.
3. 모델은 지식의 정수만을 뽑아낸 것이다.
01.지식탐구.
인쇄회로기판(PCB , printed-circuit board)설계에 특화된 소프트웨어 툴을 설계하기
해당 소프트웨어를 만들 수 있을 정도로 이해하려면 어떻게 해야 했을까?
1. PCB설계자들이 내게 말해주는 편이 좋겠다.
-> 실패.
2. 요청보고서를 보고 문뜩 떠올랐다.
- 네트(net) 란 말과 이에대한 세부사항을 발견 첫번째 도메인을 발견하다.
신호를 보낸단다.
꼭 칩이 아닐 수도 있다 그런다. (자기들은 컨포넌트 인스턴스 라 부른다고)
+ 네트에는 토폴로지가 하나씩 붙어있다 그런다.
신호는 토폴로지랑 상관없이 컴포넌트가 보낸단다.
네트간에 홉이 구성된 경로를 계산해야해서 홉을 넣어달란다.
아래는 약간 장황하게....
토폴로지는 나중에 이야기 하기로 했는데 탐침 시뮬레이션에선 사용하지 않으니깐 빼자고 하네요.
짜잔!
프로그래머와 ~ PCB설계자들의 합작품.
브레인 스토밍과 정제 그리고 질문과 설명을 통해~~~
그래서 발전한 결론은...
이렇게 되었습니다.
이같은 과정을 거쳐 탄생한 모델을 바탕으로 프로토타입을 작성!
효과적인 모델링의 요소.
1. 모델과 구현의 연계
2. 모델을 기반으로 하는 언어 정제.
3. 풍부한 지식이 담긴 모델 개발.
4. 모델의 정제.
5. 브레인스토밍과 실험.
02. 의사소통과 언어 사용.
도메인 전문가.
- 자신의 전문 용어를 사용.
개발자.
- 설계 측면에서 도메인에 관한 토론에 적합한 자신들만의 언어를 사용.
프로젝트에서 언어가 분열되면 심각한 문제가 발생한다.
애플리케이션의 특징 설명과 잘못된 의사소통의 결과로 장황하기만 하게 됩니다.
시나리오 1 : 개발자들이 알아볼수 있는 언어로 설명이 되어있다.
시나리오 2 : 누구나 볼 수 있는 언어로 설명이 되어있다.
- 결론적으로 도메인전문가와 개발자의 대화에는 시나리오 2 가 어울린다.
Comment By 회수
사용자가 이야기 했던 운항일정 이라는 용어를 객체로 표현하여 더 명확하고 구체적으로 논의할 수 있게 하였다.
도메인 기반의 용어를 사용하여 대화가 더욱 정확해 졌다.
두번째 대화에서 도메인 모델 기반의 용어를 사용하여 대화가 더욱 정확해졌다.
II. 크게 소리내어 모델링하기.
의사소통과 말하기를 분리하지 않으면 좀 더 정확하게 이해할 수 있다.
모델을 정제하는 가장 좋은 방법은 가능한 모델 변형을 구성하는 다양한 요소를 큰 소리로 말하면서 말하기를 통해 살펴보는 것이다. 그러면 다듬어지지 않은 표현은 쉽게 분간할 수 있다.
"Routing Service에 출발지 , 목적지 , 도착 시각을 전달하면 화물이 멈춰야 할 지점을 찾고, 음 그것을 데이터베이스에 삽입한다.( 모호하고 기술적임)
"출발지 ,목적지 , 등등 .. 이것들을 모두 Routing Service 에 넣으면 필요한 것이 모두 담긴 Itinerary를 돌려 받는다. (좀 더 완전해 졌지만 , 장황함)
"Routing service는 Route Specifcation 을 만족하는 Itinerary를 찾는다" (간결함)
시스템에 관해 이야기를 주고 받을 때 모델을 사용하라.
모델의 요소와 상호작용을 이용하고 모델이 허용하는 범위에 개념을 조합하면 시나리오를 큰 소리로 말해보라.
표현해야 할 것을 더 쉽게 말하는 방법을 찾아낸 다음 그러한 새로운 아이디어를 다이어그램과 코드에 적용하라.
III. 한 팀, 한 언어.
업무 전문가는~ 어쩌구 저쩌구... 탓하지 말아라 .
한 팀에서는 서로 알수 있는 공통된 언어로 이야기 해라.
d
III. 문서와 다이어그램.
시각적인 효과는 이해도를 높힐 수 있다.
모델은 다이어그램이 아니다.
UML은 만능이 아니며 모델이 나타내는 개념의 의미 모델 내 객체의 행위를 전달하지 못 한다.
잘 작성된 자바코드는 UML만큼 표현력이 있다.
선택적이고 간결한 다이어그램이 그려진 텍스트 문서로 작성하시기.
IV. 글로 쓴 설계 문서.
글로 쓴 문서로 안정과 공유를 꽤할 필요가 있다.
* 변하지 않는 형태를 가진 문서는 프로젝트 흐름과의 연광성을 잃어버리곤한다.
-> 코드는 지 나름대로 발전해가고 , 문서는 업데이트가 안 된다.
a. 문서는 코드와 말을 보완하는 역할을 해야한다.
- 실행되는 코드의 행위는 명백하다. 이에 코드 스스로 별도의 설명이 필요 없는 상태를 유지하자 ( Agile process)
코드는 세부사항(프로그램 행위를 정확하게 규명한 명세)
문서는 의미를 설명하고 , 대규모의 구조에 통찰력을 주며 , 핵심 요소에 집중할 필요가 있다.
b. 문서는 유효한 상태를 유지하고 최신 내용을 담고 있어야 한다.
설계 문서의 가장 큰 가치는 모델의 개념을 설명하고 , 코드의 세부사항을 파악해 나가는데 도움을 주며 , 모델의 의도된 사용 방식에 어떤 통찰력을 주는데 있다.
c. 문서는 프로젝트 활동과 관련을 맺고 있어야 한다.
설계문서에 설명된 용어가 대화와 코드에 나타나지 않는다면 문서 본연의 목적을 수행하고 있지 못 한거다.
연관성 없는 문서를 업데이트 하는건 노력의 낭비다.
Key Point :문서를 최소한으로 유지하고 코드와 대화를 보완하는 데 집중함으로써 프로젝트와 연관된 상태로 유지할 수 있다.
"연관성 있는 문서를" , "최소한으로" , "프로젝트와 연관된 상태를 유지" 하도록 하자.
V. 실행 가능한 기반.
의미 전달이 가능한 코드를 작성하는 방법.(추후 설명할꺼)
올바르게 실행되는 것 뿐만이 아니라 올바른 의미를 전달하는 코드를 작성하기 위해 노력을 기울이자.
의사소통을 효과적으로 하려면 코드는 요구사항을 작성하는 데 사용한 것과 동일한 언어이자 개발자가 다른 개발자와 이야기 하거나 도메인 전문가와 이야기를 나눌 때 사용하는 것과 동일한 언어에 기반을 둬야 한다.
VI. 설명을 위한 모델.
요점!. 하나의 모델이 구현 , 설계, 의사소통의 기초가 되어야 한다는 것!.
-시간상 사진 첨부 못했네요 ㅠ_ㅠ-
03. 모델과 구현의 연계.
코드와 그것의 기반인 모델이 긴밀하게 연결되면 코드에 의미가 부여되고 모델과 코드가 서로 대응하게 된다.
분석 : 도메인의 근본적인 개념을 알기 쉽고 표현력 있는 방식으로 포착해야 한다.
설계 : 대상 배포환경에서 효율적으로 수행되고 애플리케이션에서 다뤄야 할 문제를 올바르게 해결해 줄 수 있는 구성요소를 기술해야 하며 , 이러한 구성요소는 프로젝트에서 사용중인 프로그래밍 도구로 구현할 수 있어야 한다.
모델과 설계의 연계.
목표는 모델링과 설계프로세스가 단 하나의 반복고리를 형성하는 거닷!.
I.모델링 패러다임과 도구 지원.
인간의 오차 범위 내에서 정확하게 모델과 구현이 직접적으로 대응해야한다.
- 모델링 패러다임에 근거
- 모델의 구성요소에 대한 구현을 제공.
프롤로그(Prolog) 라는 언어가 MODEL DRIVEN DESIGN과 잘 어울림. - 그냥 그렇다는 이야기 였습니다.
절차적인 언어에서는 MODEL DRIVEN DESIGN을 적용하기 힘들다.
예제.
수천개의 네트 각각이 고유의 레이아웃규칙을 지니고 있다.
특정그룹에 속하는 여러 네트가 서로 동일한 규칙을 공유해야하는 것으로 본다.
예를 들면 어떤 네트들은 버스(Bus)를 구성하기도 한다.
기계적인 설계.
무모한 엔지니어의 해법.
레이아웃 도구의 데이터파일을 파싱한 다음 규칙을 파일에 삽입하는 스크립트를 작성 -> 버스에 적용.
네트 이름 컴포넌트 .핀
--------- -----------
Xyz0 A.0, B.0
Xyz1 A.1, B.1
Xyz2 A.2, B.2
네트 이름 규칙 이름 매개변수
Xyz1 min_linewidth 5
Xyz1 max_delay 15
Xyz2 min_linewidth 5
Xyz2 max_delay 15
이를 토대로 아래와 같은 맥락의 스크립트를 작성한다.
1. 네트 이름으로 네트 목록 파일을 정렬
2. 버스 이름 패턴으로 시작하는 첫 번째 네트를 찾으면서 파일의 각 줄을 읽는다.
3. 이름이 일치하는 각 줄에서 해당 줄을 파싱해서 네트의 이름을 구한다.
4. 규칙 텍스트가 있는 네트 이름을 규칙 파일에 추가한다.
5. 나머지 줄이 더는 버스 이름과 일치하지 않을 때 까지 3번 과정부터 반복한다.
이 단순한 요구사항이 변하지 않는다면 이런 스크립트를 작성하는 것이 일리 있다.
* 파일 형식이 다르면? , 좀더 풍부한 기능과 상호작용을 원한다면?
모델 주도 설계.
테스트가 성공할 수 있게 아래 처럼 구현한다.
그리고 아래 코드로 마무리
NetRuleExport.write(aFielName,NetRepository.allNets());
(서비스에서는 각 Net이 assignedRules()를 요청하게 한 다음 전부 출력한다.)
이러니깐 MODEL-DRIVEN DESIGN을 사용해야한다.
스크립트 |
확장X |
테스트 힘듬 |
MODEL-DRIVEN DESIGN |
확장 용이 |
손쉽게 테스트 |
내부 드러내기 : 모델이 왜 사용자에게 중요한가
즐겨찾기는 사실 단축아이콘 파일의 모음.
하지만 UI적으로 알아채기 힘들다.
이로인해 오해가 생긴다.
설계가 사용자와 도메인 전문가의 기본적인 관심사를 반영하는 모델에 기반을 두면
설계의 골격이 다른 설계접근법에 비해 더 큰 범위에 걸쳐 사용자에게 드러날 수 있다.
모델이 드러나면 사용자가 소프트웨어의 잠재력을 좀더 많이 접하게 되어 일관성 있고 예상 가능한 행위가 나타날 것이다.
