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 11:57] – [내부 드러내기: 왜 모델이 사용자에게 중요한가] 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> | ||
| - | **설계 혹은 설계의 주된 부분이 도메인 모델과 대응하지 않는다면** | ||
| - | 그 모델은 그다지 __가치__가 없으며 소프트웨어의 __정확함__도 의심스러워진다. | ||
| - | 동시에 모델과 설계 기능 사이의 복잡한 대응은 __이해__하기 힘들고, | ||
| - | 실제로 설계가 변경되면 __유지보수__가 불가능해진다. | ||
| - | 분석과 설계가 치명적으로 __동떨어지고__, | ||
| - | </ | ||
| - | |||
| - | <note important> | ||
| - | Model-Driven Design에서는 양쪽 모두의 목적을 달성하는 단일 모델을 찾기 위해 분석 모델과 설계를 나누는 **이분법은 채택하지 않는다.** \\ | ||
| - | **<fc red> | ||
| - | ... | ||
| - | |||
| - | (서로) 연계하는 과정에서 __기술적 고려사항 탓에__ 분석이 심각하게 타협된 상태에 놓여서는 안 된다. | ||
| - | 마찬가지로 __도메인 아이디어는 반영하지만__ 소프트웨어 설계 원칙은 따르지 않은 서툰 설계를 받아 들여서도 안 된다. | ||
| - | 이 접근법에는 분석과 설계 관점에서 모두 효과적인 모델이 필요하다. | ||
| - | |||
| - | 모델이 **구현에 대해 비현실적**이거나 **도메인 핵심 개념을 충실하게 표현하지 않을 때** 새로운 모델을 찾아내야만 한다. | ||
| - | </ | ||
| - | |||
| - | * How to? | ||
| - | * 소프트웨어 시스템의 일부를 설계할 때는 __**도메인 모델을 있는 그대로 반영해서**__ 설계와 모델의 **대응**을 분명하게 하라 | ||
| - | * (모델) 지식탐구 → (코드) 리팩터링 → ...(반복) | ||
| - | * __**Ubiquitous Langugage**를 지원하는 것__과 더불어 __분석과 설계 두 가지 측면을 충분히 만족하는 **<fc red>< | ||
| - | |||
| - | |||
| - | == 모델링 패러다임과 도구 지원 == | ||
| - | |||
| - | Model-Driven Design이 성과를 내려면 인간의 오차 범위 내에서 정확하게 모델이 직접적으로 대응해야 하는데, | ||
| - | 이를 만들어낼 수 있는 소프트웨어 도구가 | ||
| - | 뒷받침되는 모델링 패러다임 내에서 업무를 하는 것이 거의 필수적이다. | ||
| - | |||
| - | 그 도구는 **OOP**. | ||
| - | 객체 설계에서의 진정한 도약은 **코드가 모델의 개념을 표현**할 때 나온다. | ||
| - | |||
| - | 반면, Procedural 언어에서는 프로그래머가 도메인의 개념을 생각할 수 있을지언정 | ||
| - | 프로그램 자체는 데이터를 기술적으로 조작하는 것에 지나지 않기에 의미를 많이 담지 못한다. | ||
| - | |||
| - | |||
| - | |||
| - | == 내부 드러내기: | ||
| - | |||
| - | * 실제로 사용자가 바라보는 것과 시스템이 불일치한다면 혼란을 일으킬 수도 있고, 최악의 경우 버그를 유발할 수 있다. | ||
| - | * 왜 사용자가 새로운 모델을 배우게끔 만드는가? | ||
| - | |||
| - | <note important> | ||
| - | 설계가 **사용자**와 **도메인 전문가**의 **<fc red> | ||
| - | 설곅의 골격이 다른 설계 접근법에 비해 더 큰 범위에 걸쳐 __사용자에게 드러날 수 있다__. | ||
| - | 모델이 드러나면 사용자가 소프트웨어의 잠재력을 좀더 많이 접하게 되어 일관성 있고 예상 가능한 행위가 나타날 것이다. | ||
| - | </ | ||
| - | |||
| - | |||
| - | == Hands-on Modeler == | ||
| - | |||
| - | **실천적 모델러** | ||
| - | |||