14 Apr 2019

도메인 주도 설계 01 - 지식 탐구

용어

도메인: 소프트웨어가 다루는 대상 영역, 사용자의 활동이나 관심사와 관련되어 있다.
모델: 어떤 대상을 단순화하고 해석하여 문제 해결과 관련된 측면을 추상화한 것
도메인 모델: 도메인 지식을 엄격하게 구성하고 선택적으로 추상화한 것이다.

모델은 사용자의 활동이나 관련 내용을 선택적으로 단순화하고 구조화한 형태이다. 개발팀은 사용자의 활동과 관련된 지식에 집중해야 되는데, 그 폭이 너무 위압적일 수 있다. 모델은 그러한 부담을 해소하기 위한 도구이다.

도메인 모델링은 가능한 “사실적인” 모델을 만드는 문제가 아니며, 핵심 개념을 포착하고 선택적으로 추상화하여 반영하는 것이다. 불필요한 군더더기를 제거하고 문제 해결에 필요한 핵심 개념, 측면만을 다룸으로써 문제 영역의 복잡성을 감소시키는 기법이 추상화이다.

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

도메인 주도 설계에서는 아래의 세 가지 기본적인 쓰임새에 따라 모델을 선택한다.

모델과 핵심 설계는 서로 영향을 주며 구체화된다.
- 모델을 의미있게 만들고, 모델에 대한 분석 내용이 최종 산출물에 적용하게끔 하는 것은 모델과 구현 간의 긴밀한 연결이다.
  - 모델의 구현의 연결은 지속되는 유지보수와 기능개선에도 도움이 되는데, 이는 모델을 이해한 바에 코드를 해석할 수 있기 때문이다.
모델은 모든 팀원이 사용하는 언어의 중추이다.
- 모델과 구현이 연결되어 있으므로, 개발자나 도메인 전문가 사이의 의사소통에 제약이 없다.
모델은 지식의 정수만을 뽑아낸 것이다.
- 모델은 도메인 지식을 조직화하고 중요한 요소를 구분하는 팀의 합의된 방식이다.
- 모델에는 우리가 용어를 선택하고 개념을 분류하며, 분류한 지식을 서로 연관시킬 때 도메인에 관한 사고방식이 담겨 있다.
- 개발자와 도메인 전문가는 공유 언어를 바탕으로 갖가지 정보를 모델로 만들어낼 때 효과적으로 협업할 수 있다.
- 모델과 구현이 연결되어 있다면 초기 버전의 소프트웨어를 통해 얻은 경험을 바탕으로 모델링 프로세스에 피드백으로 활용할 수 있다.

소프트웨어의 본질은 사용자를 위해 도메인과 관련된 문제를 해결하는 능력에 있다. 개발자는 업무 지식을 증진하기 위해 도메인 연구에 몰두해야 한다. 또한 모델링 기법을 연마하여 도메인 설계에 통달해야 한다.

도메인 연구를 통하여 개발자와 도메인 전문가 간의 의사소통을 원활히 한다면, 도메인 전문가는 모델이 의미하는 것과 소프트웨어와 모델 간의 관계를 좀더 명확히 이해할 수 있다.

효과적인 모델링 요소

모델과 구현의 연계: 프로토타입을 토대로, 모델과 구현의 연결고리를 만들어 개발 반복 주기 내내 유지해야 한다.
모델을 기반으로 하는 언어 정제: 도메인 전문가와 개발자가 함께 모델을 정제해나감으로써, 누구라도 모델에서 바로 용어를 끄집어내어 모델의 구조와 일관되게 의사소통을 할 수 있다.
풍부한 지식이 담긴 모델 개발
모델의 정제: 연속적인 반복 주기를 통해 모델을 계속 정제하여 중요한 개념이 녹아들 수 있도록 해야하며, 불필요한 개념은 제거해야 한다.
브레인스토밍과 실험: 공통 언어를 통해 모델링 결과에 대한 평가와 시나리오 등을 검토하면서 모델의 타당성 여부를 검증해야 한다.

지식 탐구

업무나 사용자 활동에 대한 도메인 영역을 효과적으로 모델링하기 위해 지식을 면밀히 탐구해야 한다. 수많은 모델을 만들어보고 모든 세부 사항에 들어 맞는 추상적인 개념이 나타나면 초기 도메인 모델이 만들어진 것이다.
지식 탐구는 혼자서 하는 활동이 아니며, 개발자와 도메인 전문가로 구성된 팀원들이 서로 협업을 해야 한다.

과거 폭포수 개발 방식에서는 일방적으로 지식이 한 방향으로 흘러간다. 개발자는 업무 지식을 쌓을 기회가 제공되지 않으며 도메인에 숨겨진 원리는 알지 못한 채 애플리케이션에서 수행해야 할 사항만 습득하게 된다. 이는 기초적인 역할만 수행하는 소프트웨어를 만들어낼 뿐, 도메인 전문가의 사고방식과 긴밀히 연결되지 않는다.

모든 구성원이 함께 모델을 면밀히 만들어 나가면 도메인 전문가의 피드백, 협업을 통해 도메인 모델을 지속적으로 정제해나갈 수 있다. 이러한 모델은 명료하게 조직화되고 추상화될 수 있으며, 구현을 용이하게 해준다. 개발 과정에서 도메인 전문가의 지속적인 관여로 심층적인 업무 지식을 소프트웨어에 반영할 수 있다.

지속적인 학습

모든 팀 구성원이나 개발자, 도메인 전문가들이 함께 참여하는 도메인 모델링을 통해 모두 똑같이 지식을 얻고 의사소통 체계를 공유하며 구현을 거쳐 피드백 고리를 완성하는, 지식 탐구 프로세스를 궤도에 올려야 한다.

풍부한 지식이 담긴 설계

모델에 포착돼 있는 지식은 단순한 명사 찾기 이상이다. 도메인에 관련된 엔티티만큼 업무 활동과 규칙도 도메인에 매우 중요하다. 지식 탐구는 이러한 통찰력을 반영하는 모델을 만들어 낸다.

감춰진 개념 추출하기

선박 화물의 운송 예약을 위한 애플리케이션의 간단한 도메인 모델로 시작하자.

예약 애플리케이션의 책임이 각 Cargo(화물)를 하나의 Voyage(운항)와의 연관관계를 맺고, 그것을 기록/관리하는 것이라 해보자. 아마 애플리케이션에는 다음 메서드가 있을 것이다.

public int makeBooking(Cargo cargo, Voyage voyage) {
    int confirmation = orderConfirmationSequence.next();
    voyage.addCargo(cargo, confirmation);
    return confirmation;
}

보통 해운 산업에서는 선박이 운항 중에 나를 수 있는 화물의 최대치보다 예약을 더 받아들이는 것이 관행이다. 이를 초과예약(overbooking) 이라 한다.

이 요구사항을 위한 클래스 다이어그램과 코드는 다음과 같다.

public int makeBooking(Cargo cargo, Voyage voyage) {
    double maxBooking = voyage.capacity() * 1.1;
    if ((voyage.bookedCargoSize() + cargo.size()) > maxBooking)
      return –1;

    int confirmation = orderConfirmationSequence.next();
    voyage.addCargo(cargo, confirmation);
    return confirmation;
}

위와 같이 중요한 업무 규칙이 메서드의 보호절로 감춰진다. 이런 코드는 다음과 같은 문제가 있다.

업무 전문가가 이 코드를 읽고 규칙을 바로 검증하지 못한다.
해당 업무에 종사하지 않고 기술적인 측면만 담당하는 사람은 코드와 요구사항을 결부시키기 어렵다.

설계를 변경하여 이러한 지식을 더 잘 담을 수 있다. 초과예약 규칙은 일종의 정책(policy)으로, 전략 패턴을 통해 구현할 수 있다. 이러한 개념은 도메인 주도 설계의 중요한 동기에 해당한다.

public int makeBooking(Cargo cargo, Voyage voyage) {
    if (!overbookingPolicy.isAllowed(cargo, voyage)) {
      return -1;
    }

    int confirmation = orderConfirmationSequence.next();
    voyage.addCargo(cargo, confirmation);
    return confirmation;
}

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

위와 같이 구현하면 초과예약이 별개의 정책이라는 사실을 코드를 통해 분명히 알 수 있게 되며, 이 규칙의 구현 또한 명시적으로 드러나게 된다. 위의 예와 같이 지식을 보전하고 공유하는 데 도메인 모델과 그에 상응하는 설계를 이용할 수 있다.

이러한 명시적인 설계는 다음과 같은 이점이 있다.

설계를 이러한 수준까지 끌어올리려면 모든 이가 초과예약의 특성을 단순한 계산이 아니라, 별개의 중요한 업무 규칙임을 알아야 한다.
프로그래머는 업무 전문가에게 그들이 이해할 수 있는 수준에서 기술적 산출물, 코드까지 보여줄 수 있으며 이를 통해 피드백 고리가 완성된다.

심층 모델

유용한 모델은 처음부터 겉으로 드러나 있는 경우가 거의 없다. 도메인과 애플리케이션의 요구사항을 이해하게 되면서, 처음에 중요하게 생각했던 요소들을 버리거나 관점을 바꾸어 모델을 정제해나가면서 유용한 모델이 탄생하는 것이다.

이를 위해 지속적으로 지식 탐구를 도메인 전문가와 같이 진행하면서 모델을 정제해나가야 한다.

Stats:

0 comments