도메인 주도 설계(소개)

도메인 주도 설계

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

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

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

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

소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다.

그밖의 매우 중요하다 할수 있는 기능도 모두 이러한 기본적인 목적을 뒷받침하는데 불과하다.

도메인이 복잡하면 이 같은 문제 해결은 유능하고 숙련된 사람의 집중적인 노력이 필요한 어려운 일이 된다.

개발자는 업무 지식을 증진하기 위해 도메인 연구에 물두해야 한다. 그뿐만 아니라 모델링 기법을 연마해서 도메인 설계에 통달해야 한다.

예제

선박화물의 운송 예약을위한 애플리케이션

Voyage(운항) ------ Cargo(화물)

public int makeBooking(Carge carge, Voyago voyago) {

int confirmation = orderConfirmationSequence.next();

voyage.addCargo(cargo, confirmation);

return confirmation;

}

이슈발생)

항상 마지막 순간에 예약을 취소하는 경우가 있으므로 선박이 운항 중에 나를 수 있는 화물의 최대치보다 예약을 더 받아들이는 것이 해운 산업의 관행이다. 이를 초과예약(overbooking)이라한다.

조건추가) 10%초과 예약 허용

voyage   ------------Cargo

capacity              size

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;

}

중요한 업무 규칙이 애플리케이션 메서드의 보호절(guard clause)로 감춰진다.

문제이슈)

1. 코드가 작성된 대로라면 개발자의 도움이 있더라도 업무 전문가가 이 코드를 읽고 규칙을 검증하지는 못할것이다.

2. 해당 업무에 종사하지 않고 기술적인 측면만 담당하는 사람은 코드와 요구사항을 결부시키기가 어려울것이다.

문제해결방안)

설계를 변경해서 이 지식을 더 잘 담을 수 있다. 

초과예약 규칙은 일종의 정책(policy)이다.

정책이란 잘 알려진 STRATEGY 디자인 패턴의 또 다른이름이다.

대개 정책은 각종 규칙을 대체할 필요성 때문에 만들어지므로 여기서는 필요하지 않다.

그러나 우리가 담고자하는 개념은 정책이라는 의미와 잘 맞아 떨어진다.

이러한 정책도 똑같이 도메인주도설계의 중요한 동기에 해당한다.

변경)

public int makeBooking(Cargo cargo, Voyage voyage) {

if(!overbookingPolicy.isAllowed(cargo, voyage)) return -1;

int confirmation = orderConfirmationSequence.next();

voyage.addCargo(cargo, confirmation);

return confirmation;

}

OverbookingPolicy(초과예약 정책)클래스에 메서드가 포함된다.

public boolean isAllowed(Cargo cargo, Voyage voyage) {

return (carge.size() + voyage.bookedCargoSize()) <= (voyage.capacity() * 1.1);

}

이렇게 하면 초과예약이 별개의 정책이라는 사실을 모든 이가 분명하 알게 될것이며, 이 규칙의 구현 또한 명시적으로 드러나고 다른 구현과 분리된다.

더 명시적인 설계의 이점

1. 설계를 이러한 수준까지 끌어올리려면 프로그래머와 그 밖의 관련된 모든 이가 초과예약의 특성을 단순히 불분명한 계산에 불과한 것이 아니라 별개의 중요한 업무 규칙임을 알아야만 할 것이다.

2. 프로그래머는 업무 전문자에게 그들이 이해할수 있는 수준에서 기술적산출물, 심지어 코드까지 보여줄 수 있으며(안내해주면서) 피드백 고리도 완성된다.

심층모델

유용한 모델은 겉으로 드러나 있는 경우가 거의 없다.

도메인과 애플리케이션의 요구사항을 이해하게 되면서 대체로 처음에 중요하게 생각했던 피상적인 모델 요소를 버리거나 관점을 바꾼다.

처음에 나타나기 힘들지만 문제의 핵심을 관통하는 포착하기 힘든 추상화가 서서히 나타나기 시작한다.

화물을 예약하는 행위로 선적이 시작되므로 화물, 운송일정등 설명해줄 수 있는 모델을 만들었다.

하지만 도메인 전문가가 업무를 바라보는 방식을 놓쳤다.

지식탐구 끝에 화물취급이나 물맂거인 하역자업, 장소간 이동과 같은일은 주로 하도급자나 회사의 운영팀에서 수행한다는 사실을 알게됐다.

해운 전문가의 관점에서는 각 주체 사이의 갖가지 책임 이동이 존재했다.

바로 해운업자에서 일부 지역 운송업자로, 한 운송업자에서 다른 운송업자로, 마지막으로 화물 인수자까지의 법적 및 실제적인 책임 이동을 관장하는 프로세스 말이다.

종종 중요한 절차가 진행되는 동안 화물은 창고에 보관될 것이고, 또 어떤 경우에는 화물이 해운 회사의 업무 의사결정과는 무관하게 복잡한 문리적 단계를 거칠 것이다.

운송일정에 대한 세부계획보다 오히려 더 중요한 역할을 하는 것은 선하증권과 같은 법률문서와 납입양도에 이르는 절차와 같을 것이다.

해운업무를 바라보는 시야가 깊어졌다고 Itinerary(운항 일정)객체를 제거하는 것으로 이어진건 아니지만 모델은 근본적으로 바뀌었다.

해운업무를 바라보는 시각이 장소 간 컨테이너의 이동에서 엔티티와 엔티티 사이의 화물에 대한 책임 이동으로 바뀐것이다.

이러한 책임 이동을 취급하는 것과 관련된 기능이 더는 선적 작업에 부자연스럽게 붙어있는 것이 아니라 작업과 책임간의 중요한 관계를 토대로 만들어진 모델의 중심에 자리잡았다.

지식탐구는 어디서 끝날게 될지 알지 못한다.