This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| domain_driven_design:03_binding_model_and_implementation [2023/08/08 10:50] – [Model-Driven Design] ledyx | domain_driven_design:03_binding_model_and_implementation [2023/08/08 13:12] (current) – removed ledyx | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | = 03 모델과 구현의 연계 = | ||
| - | |||
| - | 종이에 기록된 모델과 동작하는 소프트웨어 간의 괴리를 어떻게 좁힐것인가? | ||
| - | |||
| - | {{tag> | ||
| - | |||
| - | == Model-Driven Design == | ||
| - | |||
| - | 모델과 코드의 괴리를 좁히는데 여러 설계 방법론에서는 분석 모델의 필요성을 지지한다. | ||
| - | |||
| - | * 분석 모델 (Analysis model) : 소프트웨어 시스템에서 수행할 역할에 대해서는 전혀 고려하지 않은 채 **업무 도메인의 개념만**을 체계화하고자 해당 업무 도메인을 분석한 결과물 | ||
| - | * 설계와 또렷이 구분되고 다른 사람들이 만든다. | ||
| - | * 오로지 **이해하기 위한 수단**으로만 간주되며, | ||
| - | * 분석 모델은 설계상의 쟁점들을 염두에 두고 만들어진 것이 아니라서 \\ 모델과 설계의 연결을 분석 모델로 진행한다는 것은 매우 **비현실적**일 가능성이 높다. | ||
| - | |||
| - | * 순수하게 이론에만 치우친 분석 모델 | ||
| - | * **도메인의 이해**라는 가장 주된 목표에 미치지 못하기도 하는데, 중요한 발견은 언제나 설계/ | ||
| - | * 결과적으로 코딩이 시작되자마자 폐기되고 대부분의 문제를 다시 검토해야 한다. | ||
| - | |||
| - | |||
| - | <note important> | ||
| - | **설계 혹은 설계의 주된 부분이 도메인 모델과 대응하지 않는다면** | ||
| - | 그 모델은 그다지 __가치__가 없으며 소프트웨어의 __정확함__도 의심스러워진다. | ||
| - | 동시에 모델과 설계 기능 사이의 복잡한 대응은 __이해__하기 힘들고, | ||
| - | 실제로 설계가 변경되면 __유지보수__가 불가능해진다. | ||
| - | 분석과 설계가 치명적으로 __동떨어지고__, | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | Model-Driven Design에서는 양쪽 모두의 목적을 달성하는 단일 모델을 찾기 위해 분석 모델과 설계를 나누는 **이분법은 채택하지 않는다.** \\ | ||
| - | **<fc red> | ||
| - | </ | ||
| - | |||
| - | |||
| - | == 모델링 패러다임과 도구 지원 == | ||
| - | |||
| - | |||
| - | == 내부 드러내기: | ||
| - | |||
| - | |||
| - | == Hands-on Modeler == | ||
| - | |||
| - | **실천적 모델러** | ||
| - | |||