[도메인 주도 설계] 03. 모델과 구현의 연계

소프트웨어를 개발하는데 직접적으로 도움을 주지 않는 도메인 모델은 의미가 없다.

도메인 주도 설계에서는 초기 분석 단계에 도움이 될 뿐 아니라 설계의 기반이 되는 모델이 필요하다.

 

MODEL-DRIVEN DESIGN (모델 주도 설계)

• 코드와 모델이 긴밀하게 연결되면 코드에 의미가 부여되고 모델과 코드가 서로 대응하게 된다.
• 설계와 모델이 대응하지 않는다면 모델은 가치가 없어지고 소프트웨어의 정확성은 의심스러워진다.
• 분석 모델(analysis model)
  • 소프트웨어 시스템에서 수행할 역할에 대해 고려하지 않고 업무 도메인의 개념만을 체계화한 모델
  • 오로지 이해하기 위한 수단으로 간주되며, 구현 관심사와 섞일 경우 혼란만 초래하는 것으로 여겨짐
  • 설계/구현 단계에서 발견된 문제들은 반영되지 못함
• 분석과 설계 관점에서 모두 효과적인 모델을 위해서는 두가지 목표가 달성되어야 한다.
  • 기술적 고려사항 탓에 분석이 심각하게 타협된 상태에 놓여서는 안된다.
  • 도메인 아이디어를 반영하기 위해 소프트웨어 설계 원칙을 위반해서은 안된다.
• 모델이 자연스럽게 소프트웨어에 구현되고, 도메인에 관한 심층적인 통찰력을 반영하도록 반복해서 리팩터링해야한다.
• 모델로부터 설계와 기본적인 책임 할당에 사용한 용어를 도출하고, 그 용어를 코드에 사용하면 코드가 모델을 표현할 수 있게 된다.

모델링 패러다임과 도구 지원

• 모델과 설계 간의 밀접한 대응을 가능하게하려면 소프트웨어 도구가 뒷받침되는 모델링 패러다임이 필요하다.
• 객체지향 프로그래밍은 모델링 패러다임에 근거하고 모델의 구성요소에 대한 구현을 제공한다.
• C언어 같은 절차적 언어에서는 대응되는 모델링 패러다임이 없기 때문에, 모델 주도 설계를 적용하기 어렵다.

예제 - 절차적인 방식에서 모델 주도적인 방식으로

• 인쇄 회로 기판(PCB)는 다수의 컴포넌트 핀을 연결하는 전도체(=네트)의 집합이다.
• PCB 레이아웃 도구 소프트웨어는 네트가 서로 교차하거나 방해하지 않게끔 모든 네트의 물리적 배열을 찾아낸다.
• 수천 개의 네트 각각이 고유의 레이아웃 규칙을 지니고 있는데, 이 규칙은 각 네트에 하나씩 할당되야 한다.

 

• 기계적인 설계
  • 1. 레이아웃 도구는 각각의 네트와 컴포넌트를 매핑한다.
    

    

  • 2. 레이아웃 규칙은 네트와 규칙 유형을 매핑한다.
    

    

  • 3. 신규 규칙이 필요하면 버스 이름으로 규칙을 추가한다.
    

    

  •  4. 버스 이름과 패턴이 일치하는 네트들에 규칙을 추가한다.
    

    

  • 위 방식의 스크립트는 단순히 파일 조작에 불과하며, 파일 형식이 바뀐다면 규칙을 적용하는 개념이 동일하더라도 처음부터 다시 시작해야 한다.
  • 이 스크립트는 정렬과 문자열 일치를 통해 버스의 존재를 추론하긴 하지만 해당 개념을 명시적으로 다루진 않는다. 
•  모델 주도 설계
  • 객체지향 언어로 객체를 구현하면 핵심 기능이 간단하게 정리된다.
    

    

  • Net 클래스의 assignedRules() 메서드는 자체적인 규칙과 Net에 포함되어 있는 Bus의 규칙을 받아들인다.
  • 필요한 로직은 간결한 서비스로 캡슐화하고, 유틸리티도 추가할 수 있다.
    

    

    

  • 핵심적인 도메인 로직을 테스트 할 수 있으며, 각 서비스와 리파지터리는 단위 테스트가 가능하다.

내부 드러내기 : 왜 모델이 사용자에게 중요한가

• 실제 사용자가 바라보는 것과 시스템이 불일치한다면 혼란을 일으키거나, 버그를 유발할 수 있다.
• 예제 : IE의 "즐겨찾기" 기능
  • 사용자 - 세션간에 지속되는 웹 사이트 이름 목록이라고 생각
  • 구현 - URL이 저장된 파일로 간주하기 때문에 윈도우 파일명으로 쓸 수 없는 문자는 허용하지 않음
  • 문제발생 - 즐겨찾기 명을 저장하는데 파일 이름에 대한 오류 메시지가 나타남
    

    

• 도메인 모델을 있는 그대로 바라보는 것은 대부분의 사용자에게 편리하지 않다. 하지만 UI에 도메인 모델이 아닌 다른 모델을 만들려는 시도는 혼란을 초래할 수 있다.
• 설계가 사용자의 관심사를 반영하는 모델에 기반을 두면, 사용자가 소프트웨어의 잠재력을 좀 더 많이 접하게 되어 일관성 있고 예상 가능한 행위가 나타날 것이다.

HANDS-ON MODELER (실천적 모델러)

• 분석과 모델링, 프로그래밍에 대한 책임을 지나치게 구분하는 것은 모델 주도 설계와 상충하며, 문제가 발생할 수 있다.
  • 모델의 전체적인 효과에 영향을 주는 세부사항이 있더라도, 그러한 세부사항은 UML 다이어그램이나 일반적인 토의 과정에서는 발견되지 않는다.
  • 모델의 구현과 기술과의 상호작용에 대한 피드백이 간접적이다. 모델의 어떤 측면이 기술 플랫폼에서 비효율적이더라도 파악하기 어렵다.
  • 코드는 모델과 무관해지며, 코드 리팩터링은 모델을 강화시키기보단 약화시킨다.
  • 모델은 구현상의 제약 조건을 감안하는 능력을 갖추지 못하고, 실용적이지 못하게 된다.
• 그러므로,
  • 모델에 기여하는 모든 기술자는 코드를 접하는데 어느 정도 시간을 투자해야만 한다.
  • 코드를 변경하는 책임이 있는 이들은 코드를 통해 모델을 표현하는 방법을 배워야 한다.
  • 모든 개발자는 모델에 관한 일정 수준의 토의에 관여해야 하고 도메인 전문가와도 접촉해야 한다.