02-심화

용어설명

• 도메인 : 지식이나 영향력,또는 활동의 영역 컴퓨터와 거의 관련이 없다.

• 핵심도메인(Core Domain) : 사용자의 목적에 중심적인 역활을 수행해서, 어플리케이션을 차별화하고 가치 있게 만드는 모델의 특징적인 부분

• 도메인 전문가 : 자신의 활동범위가 개발이 아니라, 어플리케이션 도메인의 구성원 단지 불특정 다수의 소프트웨어의 사용자가 아니라 주제 영역에 관해 깊이 있는 지식을 갖추고 있음

• 도메인모델: 도메인의 선택된 측면을 기술하고 해당 도메인과 관련된 문제를 해결하는 데 사용할수 있는 추상 체계 또는 아이디어

• 심층모델(deep model) : 도메인 전문가의 주된 관심사와 도메인과 가장 관련이 깊은 지식을 정확하게 표현한것, 심층 모델은 도메인의 피상적 측면과 초보적인 수준의 해석을 탈피함

• 도메인 계층 : 도메인 로직을 책임지는 설계와 구현에 해당하는 부분, 여기에는 도메인 모델에 대한 소프트웨어적 표현이 위치함

• 엔티티 : 근본적으로 속성이 아니라, 연속성과 식별성의 맥락에서 정의되는 객체

• 레파지터리 : 객체 컬렉션을 흉내내며, 저장,조회,검색 행의를 캡슐화하는 메카니즘

• 서비스 : 캡슐화된 상태가 없으며, 모델에 홀로 존재하는 인터페이스로 제공되는 연산

• AggreGate(집합체) : 데이터 변경을 목적으로 하나의 단위로 다뤄지는 연관 객체의 모음, 일관성 규칙이 경계내에 적용됨)

• Bounded Context(제한된 컨텍스트) : 특정 모델에 포함된 범위가 정해진 적용 가능성. 컨텍스트를 제한하면 일관성과 독립적으로 개발할수 있는가를 이해하고 서로 공유할수 있음

• Context(컨텍스트) : 단어나 문장이 해당 의미를 결정한다고 보여지는 환경

• ContextMap : 모델관계의 실제 관계를 표현한것

• Command : 시스템에 특정 변화를 초래하는 연산. 의도적으로 부수 효과(Side Effect)를 만들어 내는 연산

• Side Effect : 연산의 결과로 발생하는 모든 식별 가능한 상태 변화

• Ubiqutous Language(보편언어) : 도메인 모델에 따라 구조화되어 모든 팀원이 소프트웨어와 팀의 모든 활동을 연계하는데 사용하는 언어

• Unification(단일화) : 각 언어가 모호하지 않고 어떠한 규칙도 모순되지 않는 모델의 내적 일관성

• 도메인주도설계 : 소프트웨어 요소의 일정부분이 모델의 요소에 밀접하게 대응하는 설계,또한 서로 긴밀한 관계에 있는 모델과 구현을 함께 개발하는 과정

모델의 유용성

모델과 구현의 긴밀한 연결 : 유지보수와 기능개선에 도움이 된다.

의사소통 : 모델은 팀 구성원이 사용하는 언어의 중추가되어야하며, 도메인 전문가와 의사소통에 별도의 번역 절차가 필요없어지게 된다.

지식의정수 : 용어를 선택하고 개념을 분류하고 도메인 지식을 조직화하고 중요한 요소를 구분하는 팀의 합의된 방식

소트프 웨어의 본질

경계해야할 사항:

• 정교한 프레임워크를 만드는 작업에 착수해 기술을 바탕으로 도메인 문제를 해결하려고함
• 기술자는 자신의 기술력을 훈련할수 있는 정량적인 문제 해결에 집중을 함

패러다임 전환:

• 기술보다는 도메인 연구에 노력을 기울여야한다.
• 소프트웨어가 복잡해지는것은 기술자체가 복잡하기보다, 도메인의 복잡성에 기인하며 도메인 모델링 기법을 연마하여 도메인 설계에 집중하여 복잡성을 다뤄야한다.

지식탐구

소프트웨어를 작성할때 충분히 알지못하는 상태 ( 도메인에대한 이해 없이)에서 시작한다.  해당 프로젝트에서 다룰 지식은 단편적이고

여러군대 흩어져 있으며, 여러정보와 썩여 있어 무엇이 필요한지 알기가 어렵다. 기술적으로 어렵지 않겠지만 도메인에대한 정리가

안되어 있으며 스스로 얼마나 알지 못하는가를 깨닫지 못한다. 

지속적인 학습이 필요하며 이것은 도메인 모델링 기술과 같이 향상될수 있다.  그리고 그것은 진지하게 특정 도메인에대해 학습하는것도 포함된다.

풍부한 지식이 담긴 설계

감춰진 개념 추출하기

화물의 최대치보다 10% 예약을 더 받을수 있는 코드를 작성해보자

운송 사업자에게 기초적인 전략이고 관행이고 이것이 개발자에게 전달되면 다음과 같이된다.

• 10% 초과 예약 허용

그리고 다음과 같이 구현된다

최대예약량=운항수용량 * 1.1;

if(예약량 + 적재된량 > 최대예약량 )
    예약실패(중량초과)

여기서 이것은 올바르게 예약실패처리를 할것이다. 하지만 여기서 문제는 중요한 규칙이 숨겨졌다란것이며

다음과 같은 문제가 발생한다.

• 업무전문가가가 개발자의 도움을 받더라도, 이 코드를 검증하지 못함
• 다른 개발자는 이코드와 요구사항을 결부시키기가 어려움

여기서 지식을 더 담을수 있도록 해야하며, 초과예약 규칙은 일종의 정책(policy)이라는것이다. 

if( !예약정책.허용(화물,운항)  )
    예약실패(중량초과)

이렇게하면 초과예약이 마법상수가 아닌, 별개의 정책이라는 사실을 모든이가 알게될것이며 이 규칙의

구현 또한 명시적으로 드러나고 다른 구현과 분리가 된다.

원문의 샘플코드는 실제 다음과 같다.

public int makeBooking(Cargo cargo, Voyage voyage) {
    if(!overbookingPolicy.isAllowed(cargo, voyage)) return -1;
    int confirmation = orderConfirmationSequence.next();
    voyage.addCargo(cago, confirmation);
    return confirmation;
}

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

심층모델

실제 프로젝트에서 유용하고 명확한 모델을 만들려면 도메인지식은 물론 모델링 기법에도 정교한 솜씨가 필요하다.

운송 예약 - 선적 - 운송일정을 설명해줄수 있는 모델을 만들고 이것이 유용한것임에도 불구하고

도메인 전문가를 만족시키기 어렵다. 도메인 전문가가 업무를 바라보는 방식을 대부분 놓치기 때문이다.

도메인의 지식 탐구 끝에 화물이 이동 됨에따라  하도급이나 회사의 운영팀에의해 운영이되는등

각가지 책임이동이 존재하고, 회의 의사결정과 무관하게 복잡한 물리적 이동단계를 거치며 중요한것은

이러한 세부계획보다 법적인 절차를 따른것이 더 중요하다란 사실이다.

운송업무를 바라보는 시각이 장소간 컨테이너의 이동에서 엔티티와 엔티티 사이의 화물에대한 책임이동으로 시각이변경된것이며

이것은 지식탐구를 통해 중요한 관계를 토대로 모델의 중심으로 만들어야 한다란 것이다.

그리고 이러한 지식탐구가 모험과 같아서 어디서 끝날지 모른다란것이다.

보편언어(UBIQUTOUS LANGUAGE)

프로젝트에 사용되는 언어가 분열되면 의사소통을 무디게 하고, 지식탐구를 빈약하게 만든다.

설계측면에서 도메인에 관한 토론에 적합한 자신들만의 언어는 결국 코드 산출물에 녹아든것과

단절되게된다.  모델기반 언어는 개발자 사이에서 시스템의 산출물뿐 아니라, 업무와 기능을 기술할때도 사용해야하고

도메인 전문가와 의사소통하는것에도 해당 언어를 제공해야한다. 초기모델은 분명 제대로된 역활을 못할것이지만, 지속적으로 보편언어를 사용하고 언어공백이 발견되면

도메인 모델의 변화로 인식 될것이다. 용어의 의미가 바뀌면 클래스와 메서드의 이름을 변경하고 동작 방식도 변경을 한다.

보편언어의 변경이 곧 모델의 변화라는것을 인식해야한다.

문서와 다이어그램

UML:

• 객체의 행위와 제약조건은 그리기가 수월하지 않다.

• 다이어그램은 의사소통과 설명의 수단이며 브레인 스토밍을 촉진한다. 이것은 다이어그램이 최소화되었을때 가장 잘 달성된다.
  전체 객체 모델을 전부 포괄하는 다이어그램은 의사소통 설명이라는 목적을 달성하지 못한다.

• 설계의 생생한 세부사항은 코드에 담긴다.

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

• 설명을 위한 모델이 꼭 객체 모델일 필요는 없으며 오히러
  그렇지 않을때가 일반적으로 가장 좋다. 실제로 이러한 모델에서는
  UML사용을 자제하고 UML과 소프트웨어 설계와의 관련성에 관해
  잘못된 인상을 주지 않는 것이 좋다.

글로쓴 설계문서:

• 문서는 코드와 말을 보완하는 역활
• 문서는 코드가 이미 잘하고 있는 것을 하려고 해서는 안된다.
• 문서는 유효한 상태를 유지하고 최신 내용을 담고 있어야한다.
• 문서는 프로젝트 활동과 관련을 맺고 있어야한다.

여기서 작성된 문서는 실행가능 기반이 되어야하며, 모델에 기반하여 도메인과 일치하는

코드로 유도해야하며, 여기에 선언된 코드는 도메인 전문과와 이야기할때 사용된

보편적 언어 기반을 둬야 하며 또한 이것은 다시 도메인지식을 설명할수 있는

설명을 위한 모델이 되어야 한다란것이다.

클래스다이어그램 VS 설명을 위한 모델

모델과 구현의 연계

잘못된 모델의예:

• 도메인의 특성에만 충실한 클래스다이어그램은 각 객체를 구분짓는 경계가 없으며 코드와 설계에 어떠한 통찰도 줄수 없다.
• 얽혀있는 연관관계를 어렵게 볼수는 있었지만, 트랜잭션 무결성을 준수하면서 조작할수 있는지에대한 해석을 전혀 할수 없다.
• 모델은 구현에대한 지침을 제공하지 못했다.
• 설계는 어떠한 모델에도 근거하지 않은 개발자에의한 즉흥적 설계 

초기 분석단계에 도움이되고 설계의 기반이되는 모델이 필요함, 그 목적을위한것이 모델 주도 설계기법이며

이것에 도움이되는 다양한 모델링 접근법이 필요하며, 새로운것도 아니고 고정된것이 아니란 것이다.

 모델주도 설계

분석모델 : 의도적으로 도메인의 개념만을 체계화 하고 설명하고자 구현설계부분을 완전히 배제하고 분석한 결과물

분석단계에는 어느정도 지식탐구가 일어나지만, 구현을 위한 설계단계에서 이때의 성과가 대부분 사라짐

설계의 주된 부분이 도메인 모델과 대응하지 않는다면 그 모델은 가치가 없으며 분석과 설계가 치명적으로 불일치하여

그 통찰력이 서로에게 전해지지 않음 

고로, MODEL-DRIVEN DESIGN(모델주도설계)  에서는 분석모델이 별도로 존재하는 이분법을 채택하지 않는것이 핵심사항

코드의 변경이 곧 모델의 변경이라는 점을 인식해야하는 점과, 설계자가 구현을 하지 못해 개발자와 업무의 단절이 생기면

설계자의 지식과 솜씨는 결코 전달되지 않기때문에 실천적 모델(HANDS-ON MODELER)을 각 프로그래머가 수행해야하며

이것은 역활과는 상관없이 코드를 변경하는 책임이 있는 이들은 코드를 통해 모델을 표현하는 방법을 배워야하며

도메인전문과와의 접촉을 통해 UBIQUITOUS LANGUAGE를 토대로 모델의 아이디어를 나누는데 적극 참여를 해야한다.

Next : 03-구현