도메인 주도 설계 Domain-Driven Design    2장의사소통과 언어 사용                                아꿈사                                이영권     ...
목차2장 의사소통과 언어 사용                       p23• UBIQUITOUS LANGUAGE (보편 언어) p24• 크게 소리내어 모델링하기                p31• 한 팀, 한 언어  ...
의사소통과 언어 사용도메인 모델은 소프트웨어 프로젝트를위한 공통언어의 핵심이 될 수 있다.• 축적된 개념의 모음• 용어와 관계로 표현되며 의미체계를 제공• 코드와 연계하는데 연결고리 역할을 한다.모델기반 의사소통은 UM...
UBIQUITOUS LANGUAGE (보편 언어)유연하고 풍부한 지식이 담긴 설계를 만들려면다용도로 사용할 수 있는팀의 공유 언어(UBIQUITOUS LANGUAGE)가필요.공유 언어에 대한 활발한 실험이 필요하지만대부...
UBIQUITOUS LANGUAGE (보편 언어)UBIQUITOUS LANGUAGE를 사용하지 않는다면..• 도메인 전문가와 개발자는 서로 사용하는 전문 용어를 알지  못한다.• 개발자가 도메인 전문가가 이해 못하는 방...
UBIQUITOUS LANGUAGE (보편 언어)UBIQUITOUS LANGUAGE를 구성하는 어휘• 클래스와 주요연산• 규칙을 토론하기 위한 용어• 높은 수준의 구성 원칙 용어 (14장과 16장 CONTEXT MAP)...
UBIQUITOUS LANGUAGE (보편 언어)처음 도입시에는 언어가 역할을 다하지 못할 것이다.• 의미적 풍부함 결여• 실제적인 특징 누락• 개념의 불분명함계속 실험하고 끊임없이 적용하라.• 의사소통과 코드에 사용•...
크게 소리내어 모델링하기인간은 구어에 재능을 지니고 있으므로다른 형태의 의사소통(문서 등등?)과 말하기를분리하면 손실
크게 소리내어 모델링하기대화시 도메인 모델의 언어를 사용하지 않을 때 문제• 대화가 간결하지 못함.• 모호해지며 기술적으로 된다.
크게 소리내어 모델링하기시스템에 관해 이야기를 주고 받을 때모델을 사용하여인간의 언어적 재능을 모델을 개발하는 데 활용하라
한 팀, 한 언어종종 기술 담당자들이 업무전문가에게도메인 모델을 보여 줄 필요가 없다고 생각한다.•   “업무 전문가들에게는 너무 너무 추상적이라서요.”•   “객체를 이해 못해요.”•   “업무 전문가들이 쓰는 용어로...
한 팀, 한 언어도메인 전문가도 이해 못하는 모델은 문제가 있다.같은 언어를 사용해야 서로간의 잘못된 점을 발견할 수 있다.• 잘못 알고 있던 부분• 이해가 부족한 부분그러므로 언어의 분열이 일어나면 안된다.
한 팀, 한 언어때로는 여러 언어가 필요할 때도 있다.서로간의 이해 수준을 넘는 용어는UBIQUITOUS LANGUAGE의 확장 영역.
문서와 다이어그램문서로서의 UML다이어그램장점• UML다이어그램은 정보를 파악하는데 도움• 간결한 UML다이어그램으로 논의의 구심점 역할단점• 개념적 정의와 객체의 행위를 전해주지는 못한다.• UML로 전체 모델을 표현...
문서와 다이어그램다이어그램이 문서가 아니다.• 설계의 세부사항은 코드로 담아라• 간결한 다이어그램이 그려진 텍스트 문서를 작성해라모델은 다이어그램이 아니다.• 다이어그램은 모델을 전달하고 설명하는 데 있다.
글로 쓴 설계 문서구두의 의한 의사소통이 좋긴하지만글로 쓴 문서로 안정과 공유가 필요• 문서는 코드와 말을 보완하는 역할을 해야한다.  o 설계문서로서의 코드에는 한계가 있다.  o 코드가 이미 잘 하고 있는 것을 하면...
설명을 위한 모델구현, 설계, 의사소통에 각기   다른 모델을갖추는 것은 바람직하지 않다.하지만..모델은 도메인을 가르치는 도구로 유용하며설계 모델과는 무관한 다른 관점의 모델이 도움이 될 수 있다.설명을 위한 모델은 ...
설명을 위한 모델      설계를 위한 모델
설명을 위한 모델      설명을 위한 모델
감사합니다.
Upcoming SlideShare
Loading in...5
×

Domain driven design_chapter2

1,162

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,162
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Domain driven design_chapter2

  1. 1. 도메인 주도 설계 Domain-Driven Design 2장의사소통과 언어 사용 아꿈사 이영권 whiletrue0222@gmail.com
  2. 2. 목차2장 의사소통과 언어 사용 p23• UBIQUITOUS LANGUAGE (보편 언어) p24• 크게 소리내어 모델링하기 p31• 한 팀, 한 언어 p32• 문서와 다이어그램 p35 o 글로 쓴 설계 문서 p37 o 실행 가능한 기반 p40• 설명을 위한 모델 p41
  3. 3. 의사소통과 언어 사용도메인 모델은 소프트웨어 프로젝트를위한 공통언어의 핵심이 될 수 있다.• 축적된 개념의 모음• 용어와 관계로 표현되며 의미체계를 제공• 코드와 연계하는데 연결고리 역할을 한다.모델기반 의사소통은 UML상의 다이어그램으로 한정돼면 안 된다.• 모든 의사소통 수단에 스며들 필요가 있다.
  4. 4. UBIQUITOUS LANGUAGE (보편 언어)유연하고 풍부한 지식이 담긴 설계를 만들려면다용도로 사용할 수 있는팀의 공유 언어(UBIQUITOUS LANGUAGE)가필요.공유 언어에 대한 활발한 실험이 필요하지만대부분의 안 한다.
  5. 5. UBIQUITOUS LANGUAGE (보편 언어)UBIQUITOUS LANGUAGE를 사용하지 않는다면..• 도메인 전문가와 개발자는 서로 사용하는 전문 용어를 알지 못한다.• 개발자가 도메인 전문가가 이해 못하는 방식으로 추상화 할 수도 있다.• 공통 언어가 없다면 서로 간의 언어를 번역해줘야 한다.이 마저도 모호하다!!
  6. 6. UBIQUITOUS LANGUAGE (보편 언어)UBIQUITOUS LANGUAGE를 구성하는 어휘• 클래스와 주요연산• 규칙을 토론하기 위한 용어• 높은 수준의 구성 원칙 용어 (14장과 16장 CONTEXT MAP)• 도메인 모델에 적용하는 패턴 이름모델 기반 언어를 다방면에서 사용해야한다.• 업무와 기능을 기술할 때• 요구사항, 개발 계획, 기능에 관해 의사소통할 때
  7. 7. UBIQUITOUS LANGUAGE (보편 언어)처음 도입시에는 언어가 역할을 다하지 못할 것이다.• 의미적 풍부함 결여• 실제적인 특징 누락• 개념의 불분명함계속 실험하고 끊임없이 적용하라.• 의사소통과 코드에 사용• 대안모델을 반영하는 표현을 시도일단은...계속 언어를 사용하고 발전 시키고언어의 변화가 모델의 변화를 인식하라.
  8. 8. 크게 소리내어 모델링하기인간은 구어에 재능을 지니고 있으므로다른 형태의 의사소통(문서 등등?)과 말하기를분리하면 손실
  9. 9. 크게 소리내어 모델링하기대화시 도메인 모델의 언어를 사용하지 않을 때 문제• 대화가 간결하지 못함.• 모호해지며 기술적으로 된다.
  10. 10. 크게 소리내어 모델링하기시스템에 관해 이야기를 주고 받을 때모델을 사용하여인간의 언어적 재능을 모델을 개발하는 데 활용하라
  11. 11. 한 팀, 한 언어종종 기술 담당자들이 업무전문가에게도메인 모델을 보여 줄 필요가 없다고 생각한다.• “업무 전문가들에게는 너무 너무 추상적이라서요.”• “객체를 이해 못해요.”• “업무 전문가들이 쓰는 용어로 된 요구사항을 만들어야 해요.”여러 이유로 팀에 두가지 언어가 존재하게 된다.
  12. 12. 한 팀, 한 언어도메인 전문가도 이해 못하는 모델은 문제가 있다.같은 언어를 사용해야 서로간의 잘못된 점을 발견할 수 있다.• 잘못 알고 있던 부분• 이해가 부족한 부분그러므로 언어의 분열이 일어나면 안된다.
  13. 13. 한 팀, 한 언어때로는 여러 언어가 필요할 때도 있다.서로간의 이해 수준을 넘는 용어는UBIQUITOUS LANGUAGE의 확장 영역.
  14. 14. 문서와 다이어그램문서로서의 UML다이어그램장점• UML다이어그램은 정보를 파악하는데 도움• 간결한 UML다이어그램으로 논의의 구심점 역할단점• 개념적 정의와 객체의 행위를 전해주지는 못한다.• UML로 전체 모델을 표현하려고 할 때 문제가 발생한다. o 너무 복잡해진다.
  15. 15. 문서와 다이어그램다이어그램이 문서가 아니다.• 설계의 세부사항은 코드로 담아라• 간결한 다이어그램이 그려진 텍스트 문서를 작성해라모델은 다이어그램이 아니다.• 다이어그램은 모델을 전달하고 설명하는 데 있다.
  16. 16. 글로 쓴 설계 문서구두의 의한 의사소통이 좋긴하지만글로 쓴 문서로 안정과 공유가 필요• 문서는 코드와 말을 보완하는 역할을 해야한다. o 설계문서로서의 코드에는 한계가 있다. o 코드가 이미 잘 하고 있는 것을 하면 안 된다.• 문서는 유효한 상태를 유지하고 최신 내용을 담고 있어야 한 다. o UBIQUTOUS LANGUAGE로 작성돼야 한다. o 문서를 최소한으로 유지 코드와 대화를 보완하는 데 집중
  17. 17. 설명을 위한 모델구현, 설계, 의사소통에 각기 다른 모델을갖추는 것은 바람직하지 않다.하지만..모델은 도메인을 가르치는 도구로 유용하며설계 모델과는 무관한 다른 관점의 모델이 도움이 될 수 있다.설명을 위한 모델은 객체 모델일 필요는 없으며,그렇지 않을 때 일반적으로 가장 좋다.
  18. 18. 설명을 위한 모델 설계를 위한 모델
  19. 19. 설명을 위한 모델 설명을 위한 모델
  20. 20. 감사합니다.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×