1부 동작하는 도메인 모델 만들기(1) - 지식 탐구

도메인과 모델이란?

• 도메인

  사용자가 프로그램을 사용하는 대상 영역
  모든 소프트웨어는 사용하는 사용자의 활동이나 관심사와 관련이 있음

• 모델

  지식을 필요에 따라 단순화, 구조화, 추상화한 형태
  개발팀은 사용자의 활동과 관련된 지식체계에 집중해야 하는데, 지식의 폭이 깊거나 많은 양, 복잡성에 압도될 수 있는데, 이러한 부담을 해소할 수 있는 도구이며, 적절한 모델을 통해 정보를 이해하고 문제 자체에 집중할 수 있게 해주는 역할을 함

---

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

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

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

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

효과적으로 모델링하기 위한 요소

• 모델과 구현의 연계

  간단한 프로토타입으로 모델과 소프트웨어의 동작 간의 연결고리를 만들고, 이를 유지하며 계속하여 모델을 개선하고, 지식을 통합하고 이를 소프트웨어에 반영하는 방식을 반복한다.

  이는 동작방식에 대해 더욱 집중할 수있고, 모델과 소프트웨어의 동작 간의 관계에 대해 더 명확하게 이해할 수 있게 한다.

• 모델을 기반으로 하는 언어 정제

  프로젝트 진행 간 사용자(혹은 도메인 전문가)와 개발자, 개발자와 개발자 등 모든 참여자는 모델의 구조와 일관되게 문장을 구성할 수 있어야 하고, 별도의 해석 없이도 문장을 명확하게 이해할 수 있어야 한다.

   

  처음에 사용자 자신의 업무나 활동에 대해 설명하는 바에 대해 개발자가 곧바로 이해할 수 없고, 개발자는 알게된 지식이 올바르게 이해한 것인지 사용자와 커뮤니케이션을 할 때 다이어그램 등을 통해 직관적으로 표현하는 것에  사용자가 익숙치 않을 수 있다.
  하지만 계속해서 개발자가 이해한 지식에 대해 사용자에게 피드백을 받으며, 도메인적인 부분에 이해가 쌓이고 다이어그램 같은 개발자의 표현 방식에 사용자가 익숙해지면서 서로의 언어를 통합하고, 이해를 방해하는 동의어 같은 뜻의 말만 다른 용어들은 제외한다.
  
  결국, 무엇이 중요한지 파악하기 더 쉽게 파악할 수 있고 새로운 정보를 더 빨리 배우도록 하며 체계화할 수 있게 한다.

• 풍부한 지식이 담긴 모델 개발

  객체는 행위를 갖고 규칙을 이행한다.

  모델은 단순 데이터 스키마가 아니라 복잡한 문제를 해결하며 다양한 지식이 포함되어 있다.

• 모델의 정제

  프로젝트가 진행되며 모델은 점점 완전해진다. 필요없는 개념은 제거하고, 필요한 개념은 추가한다.

  그리고 모델의 본질과 거리가 있는 개념은 새로운 모델로 만들 수 있다.

• 브레인스토밍과 실험

  스케치, 정제된 언어를 바탕으로 브레인스토밍을 통해 모델에 대한 토의를 하고, 타당한 모델인지 평가한다.

  팀에서 시나리오를 검토할 때 시나리오에 대해 말로 표현하는 것만으로도 제안된 모델의 타당성을 빠르게 판단할 수 있다.
  이는 토의하며 들을 때 표현이 어색하거나 이상한지 혹은 이해가 쉽고 명확한지 알 수 있기 때문이다.

---

지식탐구

• 폭포수 개발 방식

  • 과거 폭포수 개발 방식에서는 한쪽으로만 진행되기 때문에 피드백이 없어 실패함

  • 모델링의 책임은 분석가에 있고, 업무 전문가가 알려주는 사항에만 근거함

  • 분석가는 개발자에게서 배우거나 초기 버전의 소프트웨어에서 경험을 쌓을 기회가 없음

  • 지식은 한쪽으로만 흐르고 축적되지 않음

• 유능한 지식 탐구자와 팀

  • 추상화를 시작하여 더욱 많은 일을 해내는 모델로 발전시킴

  • 모든 구성원이 함께 면밀하게 모델을 만들어가야 함

  • 도메인 모델의 지속적인 정제를 토대로 개발자는 기계적으로 기능개발만 하지않고, 업무의 중요 지식과 원칙들을 배워 나감

  • 도메인 전문가는 소프트웨어에서 요구하는 개념적 엄밀함(conceptual rigor)을 이해하게 됨

  • 이런 과정들을 거쳐 모델은 더욱 유용한 형태로 바뀌고 추상화되며, 구현을 용이하게 해줌

  • 모델이 점점 향상되면서 프로젝트 내내 계속해서 정보들을 조직화하는 도구로 자리잡힘

  • 모델은 요구사항 분석에 초점을 맞춤과 동시에 프로그래밍, 설계와 밀접한 관계를 맺음

  • 모델은 선순환을 통해 도메인에 대한 팀 구성원의 통찰력을 높여 더욱 분명하게 모델을 파악하게 해주고, 다시 더 높은 수준으로 정제된 모델로 발전하게 됨

---

지속적인 학습

아래와 같은 지식의 특성 때문에 팀은 지속적인 학습을 바탕으로 지식을 가지고 있도록 노력해야 한다. 

개발자에게 학습은 도메인 모델링 기술, 개발 능력, 현재 종사하는 도메인에 대한 지식 모두 포함된다.

• 지식의 특성

  • 단편적

  • 여러 사람, 문서 등에 흩어져 있으며 다른 지식과 섞여서 존재 (중요하고 필요한 정보를 잘 정제해야 함)

  • 새어나가기 쉬움
    조직개편, 퇴사 등의 이유로 도메인에 대한 지식을 충분히 학습한 사람이 빠지면 지식이 새어 나가기 쉽고,
    시간을 들여 어렵게 알아낸 지식들이 코드와 문서에서 온전히 표현되지 못하므로 사라지게 됨

---

풍부한 지식이 담긴 설계

• 업무 전문가가 코드를 읽고 규칙을 검증할 수 있을 수준이 되도록 설계 (코드 해석에 개발자의 도움을 받겠지만)
• 해당 업무에 지식이 없이 기술적인 측면만 담당하는 사람이 코드를 보았을 때 요구사항을 명확하게 이해할 수 있어아 함

// 지식을 명확학게 담은 설계
public int makeBooking(Cargo cargo, Voyage voyage) {
    if (!overbookingPolicy.isAllowed(carge, voyage)) {
    	return -1;
    }
    ...
}

public boolean isAllowed(Cargo carge, Voyage voyage) {
    return cargo.size() + voyage.bookedCargoSize() <= voyage.capacity() * 1.1;
}

// 지식을 명확학게 담지 못한 설계
public int makeBooking(Cargo cargo, Voyage voyage) {
    double maxBooking =voyage.capacity() * 1.1;
    if (voyage.bookedCargoSize() + cargo.size() > maxBooking) {
    	return -1;
    }
    ...
    ...
}

위 예제와 같은 명시적인 설계 수준의 이점

• 초과예약(overbooking policy)이 단순한 불분명한 계산이 아닌, 별개의 중요 정책이라는 사실을 모두 알게 됨
• 해당 규칙의 구현이 명시적으로 드러나고, 다른 구현과 분리됨 (OOP의 응집도와 결합도)
• 개발자는 업무 전문가에게 그들이 이해할 수 있는 수준으로 기술적 산출물과 코드를 보여주며 안내해 줄 수 있고, 이에 대한 피드백 고리도 완성시킬 수 있음

---

심층 모델

• 유용한 모델은 겉으로 드러나 있지 않음
• 중요한 지식이 통합되거나 불필요한 개념을 제거하고, 관점을 바꾸는 등 모델링이 진행되면서 문제의 핵심과 포착하기 힘들었던 부분에 대한 추상화가 나타남
• 작업과 책임 간 중요 관계가 모델의 중심에 있음