[도메인 주도 설계] 1부 : 동작하는 도메인 모델 만들기

 

도메인 모델링은 가능한 한 사실적인 모델을 만드는 문제가 아니다.

도메인 모델링은 어떤 목적에 따라 제약에 구애받지 않고 현실을 표현하는 영화 제작에 더 가깝다.

영화 제작자가 자신의 경험 가운데 몇 가지 측면을 골라 특유의 방식으로 이야기하고 논지를 펼쳐 나가듯이 도메인 모델러 또한 모델의 유용성에 따라 특정 모델을 선택한다.

 

도메인 주도 설계에서의 모델의 유용성

모델과 핵심 설계는 서로 영향을 주며 구체화된다.

모델과 구현 간의 긴밀한 연결은 모델을 의미 있게 만들고, 모델의 분석이 최종 산출물인 동작하는 프로그램에 적용되게끔 보장합니다.

 

모델은 모든 팀 구성원이 사용하는 언어의 중추이다.

모델과 구현이 서로 연결되어 있으므로 개발자와 도메인 전문가가 의사소통하는 데 별도의 번역 절차가 필요하지 않습니다.

 

모델은 지식의 정수만을 뽑아낸 것이다.

모델은 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 팀의 합의된 방식입니다.

모델에는 도메인에 관한 우리의 사고방식이 담겨 있습니다.

 

 

01장 지식 탐구

---

효과적인 모델링의 요소

1. 모델과 구현의 연계
2. 모델을 기반으로 하는 언어의 정제
3. 풍부한 지식이 담긴 모델 개발
4. 모델의 정제
5. 브레인스토밍과 실험

 

폭포수 개발 방식의 문제점

• 모델을 만들어내는데 따르는 모든 책임이 분석가에게 있음
• 이러한 모델을 오로지 업무 전문가가 알려주는 사항에만 근거
• 지식은 한 방향으로 흘러갈뿐 축적되지 않음

 

모든 구성원이 함께 모델을 만들어간다면?

개발자

• 기능만을 기계적으로 만드는데 머무르지 않고 자신이 보조하고 있는 업무의 중요 원칙을 배움

도메인 전문가

• 자신이 알고있는 지식의 정수만을 추출해내야 하므로 스스로 이해하는 바를 자주 정제
• 소프트웨어 프로젝트에서 요구하는 개념적 엄밀함을 이해

전체

• 팀 구성원은 더욱 유능한 지식 탐구자로 거듭남
• 그들은 모델과 관련 없는 것은 가려내고 모델은 더욱 유용하게 고침
• 모델은 명료하게 조직화되고 추상화될 수 있으며, 구현이 더 용이해짐

 

 

 

02장 의사소통과 언어 사용

---

모델은 프로젝트에 참여한 사람들의 머릿속에 축적된 개념을 모아 놓은 것으로서 도메인에 대한 통찰력을 반영하는 용어와 관계로 표현한다.

 

용어와 상호관계

• 기술적인 개발을 할 수 있을 만큼 충분히 정확한 동시에 도메인에 맞게 조정된 언어의 의미체계를 제공
• 모델을 개발 활동과 결부시키고 모델을 코드에 연계하는데 중요한 연결고리 역할을 함

 

모델 기반 의사소통은 UML 상의 다이어그램으로 한정돼서는 안 된다.

 

UBIQUITOUS LANGUAGE

그림 1 :: 도메인 전문가의 언어와 개발자의 언어

도메인 전문가

• 소프트웨어 개발에 사용되는 기술적 전문용어를 이해하는데 한계가 있음
• 자신이 종사하는 분야의 전문 용어는 다양하게 사용

개발자

• 전문가들의 언어에 담긴 의미는 알지 못함
• 설계는 뒷받침하나 도메인 전문가는 이해할 수 없는 방식으로 추상화할 수 도 있음

 

프로젝트에서 사용되는 언어가 분열된다면?

그림 2 :: 개발자가 세션에서 제외된다면

• 일상적인 토론에서 쓰이는 용어가 코드에 녹아든 용어와 단절
• 같은 사람인데도 말할 때나 글을 쓸 때 서로 다른 용어를 써서 도메인의 가장 간결하고 명확한 표현이 일시적인 형태로 나타났다가 코드나 문서에도 담기지 않는 결과 초래
• 번역은 의사소통을 무디게 하고 지식 탐구를 빈약하게 만듦

 

UBIQUITOUS LANGUAGE를 지속적으로 사용하면

• 모델의 취약점이 드러남
• 실험을 토대로 부자연스러운 용어나 결합의 대안을 찾아냄
• 언어에 공백이 발견되면 토론하는 가운데 새로운 단어 출현
• 이러한 용어의 변화는 도메인 모델의 변화로 인식
• 용어의 의미가 바뀌면 팀에서는 클래스 다이어그램을 수정하고, 클래스명, 메서드명을 변경하고 동작 방식도 변경

 

모델을 언어의 근간으로 사용하라

팀 내 모든 의사소통과 코드에서 해당 언어를 끊임없이 적용하는데 전념하라

다이어그램과 문서에서, 특히 말할 때 동일한 언어를 사용하라

 

대안 모델을 반영하는 대안이 되는 표현을 시도해 봄으로써 어려움을 해소하라

일상적으로 쓰는 단어의 의미에 동의를 이끌어내는 것과 같은 방식으로 대화할 때 쓰는 용어의 혼란도 해결

 

UBIQUITOUS LANGUAGE의 변화가 곧 모델의 변화라는 것을 인식하라

도메인 전문가는 도메인을 이해하는데 부자연스럽고 부정확한 용어나 구조에 대해 반대 의사를 표명해야 한다

개발자는 설계를 어렵게 만드는 모호함과 불일치를 찾아야 함

 

모델을 정제하는 가장 좋은 방법

가능한 모델 변형을 구성하는 다양한 요소를 큰 소리로 말하면서 살펴보기

모호하고 기술적임 → 좀더 완전해졌지만 장황함 → 간결함

 

시스템에 관해 이야기를 주고받을 때 모델을 사용하라

수준 높은 도메인 전문가도 해당 모델을 이해하지 못한다면 모델이 잘못된 것이다.

 

모델은 다이어그램이 아니라는 점을 항상 명심해야 한다

다이어그램의 목적은 모델을 전달하고 설명하는 데 있다.

 

문서는 코드와 말을 보완하는 역할을 해야 한다

문서는 코드가 이미 잘하고 있는 것을 하려고 해서는 안된다.

코드는 이미 세부사항을 충족하며, 프로그램의 행위를 정확하게 규정한 명세에 해당함

 

문서는 유효한 상태를 유지하고 최신 내용을 담고 있어야 한다

설계 문서의 가장 큰 가치는 모델의 개념을 설명하고, 코드의 세부사항을 파악해 나가는 데 도움을 주며, 모델의 의도된 사용 방식에 어떤 통찰력을 주는 데 있음

 

 

 

03장 모델과 구현의 연계

---

분석 모델(analysis model)

• 소프트웨어 시스템에서 수행할 역할에 대해서는 전혀 고려하지 않은 채, 업무 도메인의 개념만을 체계화하고자 해당 업무 도메인을 분석한 결과물
• 순수하게 이론에만 치우친 분석 모델은 도메인의 이해라는 가장 주된 목표에 미치지 못하는 경우가 있음. 중요한 발견은 언제나 설계/구현을 위해 노력하는 가운데 나타나기 때문임.

 

설계 혹은 설계의 주된 부분이 도메인 모델과 대응하지 않는다면 그 모델은 그다지 가치가 없으며, 소프트웨어의 정확함도 의심스러워진다.

 

모델 주도 설계(Model-Driven Design)

코드와 그것의 기반이 되는 모델이 긴밀하게 연결되면 코드에 의미가 부여되고 모델과 코드가 서로 대응하게 된다.

분석 단계

• 도메인의 근본적인 개념을 알기 쉽고 표현력 있는 방식으로 포착해야 함

설계 단계

• 대상 배포 환경에서 효율적으로 수행되고 애플리케이션에서 다뤄야 할 문제를 올바르게 해결해줄 수 있는 구성요소를 기술
• 이러한 구성요소는 프로젝트에서 사용 중인 프로그래밍 도구로 구현할 수 있어야 함

주요 원칙

• 모델과 설계를 연계하는 과정에서 기술적 고려사항 탓에 분석이 심각하게 타협된 상태에 놓여서는 안 된다.
• 도메인 아이디어는 반영하지만 소프트웨어 설계 원칙은 따르지 않은 서툰 설계를 받아들여서도 안 된다.
• 모델이 구현에 대해 비현실적으로 보인다면 새로운 모델을 찾아내야만 한다.
• 모델이 도메인의 핵심 개념을 충실하게 표현하지 않을 때도 새로운 모델을 찾아내야만 한다.

 

소프트웨어 시스템의 일부를 설계할 때는 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응을 분명하게 하라

모델을 재검토해서 더운 자연스럽게 소프트웨어로 구현될 수 있게 수정하라.

견고한 UBIQUITOUS LANGUAGE를 지원하는 것과 더불어 분석과 설계의 두 가지 측면을 충분히 만족하는 단 하나의 모델을 만들어 내야 함

 

모델로부터 설계와 기본적인 책임 할당에 사용한 용어를 도출하라

코드를 작성할 때 그러한 용어를 사용하면 코드가 모델을 표현한 것이 되고, 코드의 변경이 곧 모델의 변경으로 이어질 수 있다

 

 

실천적 모델러(Hands-on Modeler)

코드를 작성하는 사람이 모델에 책임을 느끼지 못하거나 애플리케이션을 대상으로 모델이 동작하게 만드는 법을 모른다면 그 모델을 소프트웨어와 무관해진다.

코드의 변경이 곧 모델의 변경이라는 점을 개발자가 인식하지 못한다면 리팩터링은 모델을 강화하기보다 약화시킬 것

모델러가 구현 프로세스와 분리돼있을 경우 구현 상의 제약 조건을 감안하는 능력을 결코 갖추지 못하거나 금방 잃어버릴 것

 

모델러가 구현 프로세스와 분리돼 있을 경우, 구현상의 제약조건을 감안하는 능력을 결코 갖추지 못하거나 금방 잃어버릴 것이다.

 

모델에 기여하는 모든 기술자는 프로젝트 내에서 수행하는 일차적 역할과는 상관없이 코드를 접하는 데 어느 정도 시간을 투자해야만 한다.

코드를 변경하는 책임이 있는 모든 이들은 코드를 통해 모델을 표현하는 법을 반드시 배워야 한다.

모든 개발자는 모델에 관한 일정 수준의 토이에 깊이 관여해야 하고 도메인 전문가와도 접촉해야 한다.

다른 방식으로 모델에 기여하는 사람들은 의식적으로 코드를 접하는 사람들과 UBIQUITOUS LANGUAGE를 토대로 모델의 아이디어를 나누는 데 적극 참여해야 한다.

 

 

 

Reference

---

도메인 주도 설계 - 교보문고

Part 1: Domain Driven Design like a pro 🏅