동작하는 도메인 만들기 | 01 - 03

동작하는 도메인 만들기

 

모델 : 어떤 사실을 해석한 것

도메인 : 사용자가 프로그램을 사용하는 대상 영역

• 실체가 있는 것 : 항공권 예약 프로그램의 실제 승객
• 실체가 없는 것 : 회계 프로그램의 화폐와 금융

 

모델의 유용성

1. 모델을 의미있게 만들어 프로그램에 적용되게끔 보장하는 것은 모델과 구현 간의 긴밀한 연결이다.
2. 개발자와 도메인 전문가가 의사소통하는데 별도의 번역 절차가 필요하지 않다.
3. 모델은 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 팀의 합의된 방식이다.

 

소프트웨어의 본질

• 소프트웨어의 본질은 도메인에 관련된 문제를 해결하는 능력에 있다.
• 도메인 연구에 몰두하고 모델링 기법을 연마해서 도메인 설계에 통달해야 한다.

---

01 지식 탐구

 

도메인 전문가와 개발자

• 전문가가 개발자에게 일방적으로 설명해주는 것은 좋지 않다.
• 객체 상호작용 다이어그램을 그리면서 서로의 이해도를 맞추는 과정이 필요하다.
• 특정한 한가지 기능만 연구하면서 모델을 발전시켜 나간다.

 

효과적인 모델링의 요소

1. 초기 프로토타입을 토대로 연결고리를 만든 후 모든 반복 주기 내내 그 연결고리를 유지한다.
2. 누구든 모델을 토대로 설명하고 별도의 해석없이 문장을 명확히 이해할 수 있다.
3. 객체는 행위를 지니고 규칙을 이해하며 다양한 지식이 포함되어 있다.
4. 모델이 점차 완전해지면서 중요한 개념이 더해지고 중요하지 않은 개념은 제거된다.
5. 브레인 스토밍을 통해 시나리오를 말로 표현하기만 해도 제안된 모델의 타당성을 판단할 수 있다.

 

지식 탐구

• 도메인 전문가와 개발자는 함께 정보를 받아들여 각자만의 경험을 토대로 유용한 형태로 만든다.
• 전문가는 자신이 이해하는 바를 자주 정재하고 소프트웨어에서 요구하는 개념적 엄밀함을 이해한다.
• 개발자는 기능을 만드는데만 머무르지 않고 자신이 하고 있는 업무의 중요 원칙들을 배운다.

 

지속적인 학습

• 지속적인 학습을 통해 도메인에 대한 지식을 갖춰야 한다.
• 전문가와 대화하고 주요 개념을 이해하며 만들고 있는 소프트웨어가 정상적으로 동작하는지 점검할 수 있어야 한다.
• 팀 구성원이 모두 똑같이 지식을 얻고 의사소통 체계를 공유하며 구현 및 피드백 고리를 완성하는 일이다.

 

풍부한 지식이 담긴 설계

• 도메인 전문가는 모든 업무 규칙을 차례로 확인하고 모순되는 상황을 조정하며 상식적인 선에서 규칙의 빈틈을 메워야 한다.
• 이때 소프트웨어 개발자와의 긴밀한 협업 하에서 진행되는 지식 탐구를 통해 이뤄진다.

중요한 업무 규칙이 감춰진 나쁜 예시

규칙이 명시적으로 드러난 좋은 예시

---

02 의사소통과 언어 사용

 

도메인 모델

• 도메인 모델은 소프트웨어를 위한 공통 언어의 핵심이다.
• 모델을 가장 효과적으로 사용하려면 모든 의사소통 수단에 사용해야 한다.

 

보편언어 (Ubiquitous Language)

• 도메인 전문가나 개발자는 자신의 전문 용어를 사용한다.
• 프로젝트에서 각자 사용하는 언어가 다르면 의사소통을 무디게 하고 지식 탐구를 빈약하게 만든다.
• 모델 기반 언어는 개발할 때만 사용하는 것이 아니라 업무와 기능을 기술할 때도 사용한다.
• 모든 상황에서 모델 기반 언어를 사용해야 복잡한 아이디어를 최대한 간결하게 표현할 수 있는 모델을 만들 수 있다.
• 모델을 언어의 근간으로 사용하여 팀 내 모든 의사소통과 코드에서 해당 언어를 끊임없이 적용한다.
• 전문가는 부자연스럽고 부정확한 용어나 구조에 대해 표명해야 한다.
• 개발자는 모호하거나 어딘가 맞지 않는 부분을 찾아내야 한다.

 

크게 소리내어 모델링하기

• 모델을 정제하는 가장 좋은 방법은 모델의 여러 요소들을 큰 소리로 말하면서 살펴보는 것이다.
• 다이어그램을 그려 시각적/공간적 추론 능력을 활용하는 것도 중요하지만 말하면서 곱씹어보는 것도 중요하다.
• 다이어그램과 문서만으로는 충족될 수 없는 부분이 자연스럽게 말로써 해당 모델과 언어를 이해할 수 있게 된다. 
  • Routing Service에 출발지, 목적지, 도착 시각을 전달하면 화물이 멈춰야할 지점을 찾고, 데이터베이스에 삽입한다.
    → 모호하고 기술적이다.
  • 출발지, 목적지 등을 Routing Service에 넣으면 필요한 것이 모두 담긴 Itinerary를 돌려받는다.
    → 좀 더 완전해졌지만 아직 장황하다.
  • Routing Service는 Route Specification을 만족하는 Itinerary를 찾는다.
    → 간결하다.

 

한 팀, 한 언어

• 도메인 전문가는 해당 분야에 대해 심층적으로 사고할 수 있는 능력을 갖추고 있다고 가정한다.
• 수준 높은 전문가도 해당 모델을 이해하지 못한다면 모델은 잘못 만들어진 것이다.
• 전문가와 개발자는 시나리오를 토대로 모델 객체를 단계적으로 사용해보면서 모델을 정제해나간다.
• 이 과정에서 점차 서로의 개념 이해와 정제가 깊어진다.

개발자 전문용어 + UBIQUITOUS LANGUAGE + 전문가 전문용어

 

문서와 다이어그램

• 어떤 특정한 종류의 정보를 파악할 때 다이어그램이 도움이 된다.
• 구두로 하는 논의에서 객체의 이름, 객체 간의 관계를 바라보는 관점 등을 나타낼 수 있어 이해를 높인다.
• 모델이 나타내는 개념의 의미나 모델 내 객체의 행위 등 다이어그램으로 표현할 수 없는 내용들은 텍스트로 나타낸다.
• 설계를 이해하는데 필수적인, 개념적으로 중요한 부분만을 나타내는 단순화/최소화된 다이어그램이 도움이 된다.
• 설계의 생생한 세부사항은 코드에 담긴다.
• 모델은 다이어그램이 아니라는 점을 항상 명심해야 한다.

 

글로 쓴 설계 문서

• 모든 사람을 모델과 연결하는데 말하기가 결정적인 역할을 한다.
• 이렇게 말로 나눈 내용들을 어느 정도는 문서로 작성해 안정과 공유를 꾀할 필요가 있다.

 

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

• 문서나 다이어그램은 최신 상태를 유지하고 있지 않을 수 있지만 코드는 항상 최신을 유지하고 있다.
• 그러나 설계 문서로써 코드는 한계가 있다.
• 코드의 세부사항에 압도될 수 있으며 코드 이면에 존재하는 의미를 전달하기 어렵다.
• 코드는 개념을 직관적으로 구현하고 문서는 의미를 설명한다.
• 문서는 코드가 이미 잘 이해하고 있는 것을 하려고 해서는 안된다.

 

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

• 설계 문서는 모델의 개념을 설명하고 코드의 세부사항을 파악하는데 도움을 준다.
• 더불어 모델의 의도된 사용 방식에 대한 통찰력을 준다.
• 문서는 현재 프로젝트에서 사용하는 언어와 코드에 포함된 언어로 작성한다.
• 문서를 최소한으로 유지하고 코드를 보완하는데 집중해야 문서를 프로젝트와 연관된 상태로 유지할 수 있다.

 

실행 가능한 기반

• 올바르게 실행되는 것뿐만 아니라 올바른 의미를 전달하는 코드를 작성해야 한다.
• 코드의 행위, 의도, 메시지를 일치시키려면 어떤 특정한 사고방식이 필요하다.
• 의사소통을 효과적으로 하려면 코드를 작성하거나 다른 동료와 대화할 때 동일한 언어를 사용해야 한다.

 

설명을 위한 모델

• 모델은 도메인을 설명하는 도구로 하나의 모델이 구현, 설계, 의사소통의 기초가 되어야 한다.
• 기술적 모델은 기능을 수행하는데 필요한 최소한의 수준으로 범위를 줄여야 한다.
• 설명을 위한 모델은 도메인의 여러 측면을 포함하고 있으며 기술적 모델을 명확하게 하는 근거를 제공한다.

설명을 위한 모델 예시

---

03 모델과 구현의 연계