This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| domain_driven_design [2023/08/01 23:33] – 1부 서문 요약 ledyx | domain_driven_design [2023/08/08 13:15] (current) – created ledyx | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | = Domain Driven Design = | + | # |
| - | + | ||
| - | 복잡한 도메인(문제 영역)을 이해하고 모델링하고, | + | |
| - | + | ||
| - | 본문 내용 출처 : [[https:// | + | |
| - | + | ||
| - | {{tag> | + | |
| - | + | ||
| - | == 서문 == | + | |
| - | + | ||
| - | {{:: | + | |
| - | + | ||
| - | == 1부 동작하는 도메인 모델 만들기 == | + | |
| - | + | ||
| - | Part I: Putting the Domain Model to Work | + | |
| - | + | ||
| - | + | ||
| - | === 용어 정의 === | + | |
| - | + | ||
| - | + | ||
| - | ==== 도메인 ==== | + | |
| - | + | ||
| - | 대개 컴퓨터와 관련 없다 | + | |
| - | + | ||
| - | * 사용자가 프로그램을 사용하는 대상 영역 | + | |
| - | * 사용자의 활동 | + | |
| - | * 사용자의 관심사 | + | |
| - | + | ||
| - | + | ||
| - | ==== 모델 ==== | + | |
| - | + | ||
| - | 도메인 지식의 부담을 해소하기 위한 도구 | + | |
| - | + | ||
| - | * 대상을 **단순화** 한 것 | + | |
| - | * 어떤 사실을 해석한 것 | + | |
| - | * 당면의 문제를 해결하는 것과 관련된 측면으로 추상화 | + | |
| - | * 그 밖의 중요하지 않은 세부사항에는 주의를 기울이지 않는다! | + | |
| - | * 도메인 지식을 **선택적으로 단순화**하고 **의식적으로 구조화**한 형태 | + | |
| - | * 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 **팀의 합의된 방식** | + | |
| - | + | ||
| - | + | ||
| - | ==== 도메인 모델 ==== | + | |
| - | + | ||
| - | * 특정한 다이어그램이 아니라\\ **다이어그램이 전달하고자 하는 아이디어** | + | |
| - | * 도메인 지식을 **엄격하게 구성**하고 **선택적으로 추상화**한 것 | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | === 도메인 주도 설계에서의 모델의 유용성 === | + | |
| - | + | ||
| - | DDD에서는 아래의 세 가지 기본적인 쓰임새에 따라 모델을 선택한다 | + | |
| - | + | ||
| - | - 모델과 핵심 설계는 **서로 영향을 주며 구체화**된다 (3장 참고) | + | |
| - | * 모델을 의미 있게 만들고 \\ 모델의 분석이 최종 산출물인 동작하는 프로그램에 적용되게끔 보장하는 것은 \\ **모델과 구현 간의 긴밀한 연결** | + | |
| - | * 모델을 이해한 바에 근거해 코드를 해석할 수 있기 때문 | + | |
| - | - 모델은 모든 팀 구성원이 사용하는 **언어의 중추** | + | |
| - | * 모델과 구현이 서로 연결 → 개발자와 도메인 전문가간의 **번역**이 필요하지 않음 | + | |
| - | - 모델은 **지식의 정수**만을 뽑아낸 것이다 | + | |
| - | * 모델은 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 팀의 합의된 방식 → 공유 언어 사용!! | + | |
| - | + | ||
| - | + | ||
| - | === 소프트웨어의 본질 === | + | |
| - | + | ||
| - | 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력. 그뿐만 아니라 모델링 기법을 연마해서 | + | |
| - | 도메인 설계에 통달해야 한다. | + | |
| - | + | ||
| - | 대부분의 유능한 개발자는 다뤄야 할 특정 도메인을 학스하는 데 관심이 많지 않으며, | + | |
| - | 더군다나 도메인 모델링 기법을 쌓는 데는 더더욱 전념하지 않는다. | + | |
| - | 엔지니어들은 자신의 기술력을 훈련할 수 있는 정략적인 문제를 좋아한다. | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | == 2부 모델 주도 설계의 기본 요소 | + | |
| - | + | ||
| - | Part II: The Building Blocks of a Model-Driven Design | + | |
| - | + | ||
| - | + | ||
| - | == 3부 더 심층적인 통찰력을 향한 리팩터링 == | + | |
| - | + | ||
| - | Part III: Refactoring Toward Deeper Insight | + | |
| - | + | ||
| - | + | ||
| - | == 4부 전략적 설계 == | + | |
| - | + | ||
| - | Part IV: Strategic Design | + | |