도메인 주도 설계 - 도메인 주도 설계란?

도메인 주도 설계 - 나루세 마사노부 책 요약

 

왜 도메인 주도 설계가 필요한가?

• 소프트웨어는 항상 진화하는 존재이다. 개발 속도를 우선시한 소프트웨어는 유연성이 떨어지며 변화에 대응하기 어렵다. 소프트웨어가 변화에 제대로 대응하려면 개발자가 지속해서 소프트웨를 수정해야 한다. 끝없는 땜질식 수정 업무에서 벗어나기 위한 수단 중 하나가 도메인 주도 설계인 것이다. 
• 도메인 주도 설계는 도메인에 주목해 요구사항 분석부터 설계, 개발에 이르기까지 소프트웨어 개발 과정에 상호작용이 필요하다. 도메인 주도 설계의 진정한 가치가 드러나는 것은 변화에 대응해 소프트웨어를 수정할 때이다. 

 

도메인 주도 설계란 무엇인가?

• 개발자가 이용자들이 겪는 문제를 해결하려면 당연히 이용자의 세계에 대해 배워야한다. 그러나 이렇게 배운 지식이 소프트웨어 개발에서 유용한 경우는 드물다. 
• 예를 들며 물류 시스템에서 트럭이라는 단어의 어원이 쇠바퀴를 의미하는 라틴어에서 온 것이라는 지식은 물류 시스템을 개발할 때 그리 가치가 없다. 따라서 지식을 취사선택할 필요가 있다.
• 이용자에게 유용한 소프트웨어를 개발하려면 가치 있는 지식과 그렇지 않은 지식을 신중하게 구분해서 가치 있는 지식만 코드에 녹여 넣어야 한다. 이렇게 작성된 코드는 유용한 지식을 정리해놓은 문서와도 같다. 
• 개발자가 소프트웨어를 개발하면서 가치있는 지식과 그렇지 않은 지식을 잘 구분하려면 어떤 능력이 필요할까? 당연한 말이지만, 먼저 소프트웨어 이용자의 세계를 이해해야한다. 유용한 소프트웨어를 만들려면 이용자의 문제가 무엇인지 파악하고 이를 해결할 수 있는  최선의 수단을 생각해야한다. 
• 도메인 주도 설계는 이러한 고찰을 반복하는 설계를 통해 이용자의 세계와 소프트웨어 구현을 연결 짓는 것이 목적이다. 
• 내가 익힌 지식은 그것이 무엇이든 내 삶의 시간을 어느정도 들인 소중한 것이다. 지식을 코드로 녹여내 소프트웨어를 만들고, 그 소프트웨어가 직접 누군가를 돕는 것을 보며 느끼는 보람을 맛보지 못한 개발자는 없을 것이다. 도메인 주도 설계는 지식을 코드에 녹여 넣을 수 있게 하는 개념이다. 

 

도메인 지식에 초점을 맞춘 설계 기법

• 도메인이란?
  • 도메인은 '영역'이라는 뜻이다. 특히 소프트웨어 개발에서 말하는 도메인은 '프로그램이 쓰이는 대상 분야'라는 의미로 쓰인다. 여기서 더 중요한 것은 도메인에 포함되는 것이 무엇인가 하는 것이다.
  • 다시 회계 시스템을 예로 들면, 회계 분야에는 금전 혹은 장부와 같은 개념이 등장한다. 이 개념은 회계 시스템의 도메인에 속한다. 물류 시스템에는 회계 시스템에 없는 화물이나 창고, 운송수단 등의 개념이 있을 것이고 이 개념 역시 물류 시스템의 도메인에 속한다. 이렇듯 도메인에 포함되는 개념은 시스템의 대상 분야가 무엇인지에 따라 크게 달라진다. 
  • 소프트웨어의 목적은 도메인에서 이용자들이 직면한 문제를 해결하려는 것이다. 이용자들이 직면한 문제를 해결하려면 무엇이 필요할까? 이용자들의 문제를 정확히 이해하는 것이다. 이용자들이 어려움을 겪는 부분이 무엇이고 해결하고자 하는 문제가 무엇인지 알려면 이용자들의 관점이나 생각, 그들이 처한 환경을 제대로 이해해야 한다. 다른 말로 하면, 이용자들의 도메인을 접해야한다.  
  • 도메인에 속하는 개념과 사건을 이해하고 그중에서 문제 해결에 유용한 것을 뽑아낸 지식을 소프트웨어에 반영하는 과정은 소프트웨어 개발에 꼭 필요한 과정이다. 
  • 최신 프레임워크나 개발 기법, 최신 기술 등의 키워드는 개발자를 흥분시키는 단어이다. 기술을 중시하는 개발자는 기술적 접근법으로만 문제를 해결하려 들기 쉽다. 그 결과, 목적 없는 소프트웨어가 만들어지는 참사가 발생한다. 
  • 이런 비참한 결과를 피하기 위해서라도 소프트웨어가 사용될 분야(도메인)의 지식에 초점을 맞춰야 한다. 주의 깊게 관찰하고 관찰을 통해 알게 된 지식을 제대로 표현하는 것은 소프트웨어 개발 과정의 일부다. 

 

도메인 모델링이란 무엇인가?

• 모델링이라는 단어는 개발자에게 친숙하다. 모델은 현실에 일어나는 사건 혹은 개념을 추상화한 개념이다. 추상이란 여러 사물 혹은 개념에서 공통적인 것을 뽑아 파악하는 것으로 현실의 모든 것을 반영하는 것이 아니다. 상황에 따라 취사선택이 필요하다. 무엇을 버리고 취할지는 도메인에 따라 결정된다. 
• 펜을 예로 든다면, 소설가의 관점에서 펜은 도구이며 글자를 쓸 수 있다는 것이 중요한 성질이다. 반면 문구점에서 본 펜은 상품이다. 글자를 쓸 수 있다는 기능보다 상품으로서의 가치가 더 중시된다. 같은 대상이라도 중점이 달라질 수 있다는 점이다.
• 사건 혹은 개념을 추상화 하는 작업을 모델링이라고 한다. 그리고 모델링의 결과를 모델이라고 한다. 도메인 주도 설계에서는 도메인 개념을 모델링한 모델을 도메인 모델이라고 한다.

 

지식을 코드로 나타내는 도메인 객체

• 도메인 모델은 어디까지나 개념을 추상화한 지식이다. 아쉽게도 이것만 가지고는 문제를 해결할 수 없다. 도메인 모델은 어떤 매체를 통해 표현되어야만 문제를 해결할 힘을 갖는다. 
• 도메인 모델을 소프트웨어 형태의 동작하는 모듈로 나타낸 것이 도메인 객체다. 
• 어떤 도메인 모델을 도메인 객체로 구현할지도 중요한 문제이다. 개발자는 유용한 모델과 그렇지 않은 모델을 구분해야 한다. 
• 소프트웨어 이용자가 처한 세계는 항상 같은 상태로만 존재하지 않는다. 사람이 하는 일은 바뀌기 쉽고, 시간에 따라 변화하기 쉽다. 그 대부분은 경미한 변화가 쌓인 것이지만, 때로는 상식조차 뒤바뀌는 경우도 있다. 이럴 때 도메인 객체가 도메인 모델을 충실히 반영하고 있다면 도메인의 변화를 코드로 쉽게 옮길 수 있다. 
• 도메인 개념 <-> 도메인 모델 <-> 도메인 객체 (반복)
  • 도메인에 발생한 변화는 우선 도메인 모델로 전달돼야 한다.
  • 도메인 개념이 투영된 도메인 모델은 이 변화를 충실하게 반영할 수 있다. 도메인 객체는 도메인 모델이 구현된 표현이므로 바뀐 도메인 모델이 도메인 객체를 비교하면 어디를 고쳐야할지 알 수 있다.
  • 반대로 도메인 객체가 도메인에 대한 속성을 변화시키는 경우도 있다. 도메인에 대한 어중간한 이해는 도리어 구현을 방해한다. 이를 해결하려면 도메인 모델을 직시하고 도메인의 개념을 추상화하는 방법을 바꿔야한다. 

 

이 책의 접근법과 목표 

• 도메인 주도 설계를 이해하기는 쉽지 않다. 도메인 주도 설계를 공부하다 보면 수많은 개념과 용어에 놀아나는 기분이 들 것이다.
• 도메인 주도 설계와 관련된 개념 혹은 용어를 이해하려면 그 결론에 이르는 과정을 이해하기 위해 더 많은 배경지식이 필요하다.
• 도메인 주도 설계의 프랙티스 자체에 애초에 실천하기 어려운 것이 있다. 지식을 이해하는 가장 좋은 방법은 그 지식을 실천하는 것이다. 그러나 도메인 주도 설계의 실천 중에는 환경을 갖추지 못하면 실천이 어려운 것들이 있다.
• 이 책에서는 이해와 실천이 힘든 것들은 일단 제쳐두고 상대적으로 이해하기 쉽고 실천하기도 쉬운 구현 패턴에 집중해 상향식(Bottom-up)으로 설명하는 방식을 택했다. 개념에서 전제가 되는 지식 역시 그때그때 필요한 내용을 설명할 것이다. 이런 식으로 이해의 영역을 조금씩 넓혀가며 도메인 주도 설계의 본질에 접근할 준비를 하는 것이 이 책의 목표이다. 

 

• 이들은 도메인 주도 설계의 대표적인 패턴이다. 
• 지식 표현을 위한 패턴
  • 값 객체
  • 엔티티
  • 도메인 서비스
• 애플리케이션을 구성하는 패턴
  • 리포지토리
  • 애플리케이션 서비스
  • 팩토리
• 지식 표현을 위한 고급 패턴
  • 에그리게이트
  • 명세

위 순서대로 책에서는 설명할 예정이다.

 

지식 표현을 위한 패턴

• 객체 형태로 도메인 지식을 나타내는 도메인 객체를 이해하는 것부터 시작하겠다.
• 값 객체는 그 도메인만의 고유 개념(금전, 제조번호 등)을 값으로 나타내는 패턴이다. 개념과 목적 모두 이해하기 쉽기 때문에 도메인 주도 설계에서 배우는 첫 번째 기념으로 적당하다.
• 그다음 패턴은 엔티티다. 값 객체와 동일하게 개념을 나타내기 위한 객체이지만 값 객체를 배운 다음에 이해해야 엔티티를 이해할 수 있다.
• 도메인 서비스는 값 객체나 엔티티로는 표현할 수 없는 지식을 다루기 위한 패턴이다. 

 

애플리케이션을 구성하기 위한 패턴

• 지식을 표현하는 방법을 익힌 다음에는 이용자의 필요를 만족시킬 수 있는 애플리케이션을 구성하는 방법을 학습해야 한다.
• 리포지토리는 데이터의 저장과 복원을 의미하는 데이터 퍼시스턴시(Data persistency)를 담당하는 객체이다. 데이터 퍼시스턴시라고 하면 관계형 데이터베이스와 같이 구체적인 데이터스토어를 떠올리기 쉬운데, 리포지토리는 이들을 추상화한 개념이다. 
• 값 객체, 엔티티, 도메인 서비스, 리포지토리 이렇게 4가지 요소를 익히면 애플리케이션을 구성하기 위해 필요한 최소한의 개념을 이해한 것이다. 
• 애플리케이션 서비스는 이 4가지 요소가 협조하며 애플리케이션으로서 기능하는 장소가 된다. 
• 팩토리는 객체를 만드는 데 필요한 지식에 특화된 객체다. 구조가 복잡한 객체는 객체를 만드는 방법도 복잡하게 마련이다. 이 점은 도메인 객체도 마찬가지이므로 복잡한 객체를 만드는 방법도 일종의 지식으로 취급한다. 
• 객체 생성은 애플리케이션 어디서든 일어나는 일이다. 대책을 마련하지 않으면 번잡한 객체 생성 절차가 코드 이곳저곳에 중복되며 해당 코드의 의도를 파악하기 어려워진다. 팩토리패턴을 이용해 객체 생성에 대한 지식을 한곳에 모아 놓으면 도메인 객체가 더 잘 드러나며 그만큼 코드의 의도를 쉽게 이해할 수 있다. 

 

지식 표현을 위한 고급패턴

• 애그리게이트와 명세는 지식을 표현하기 위한 고급 패턴이다. 
• 애그리게이트는 무결성을 유지하는 경계이다. 값 객체나 엔티티 같은 도메인 객체를 한데 묶어 복잡한 도메인 개념을 나타낸다. 요구되는 배경지식이 많기 때문에 이해하기도 어렵고 그만큼 바르게 실천하기도 어려운 개념이다. 
• 명세는 객체를 평가하기 위한 지식이다. 객체가 어떤 특정한 조건을 만족하는지 판정하는 평가 기준을 객체 내에 구현하면 개체가 이런 내용의 코드로 인해 불필요하게 복잡해질 수 있다. 명세 패턴을 적용하면 객체를 평가하는 기준을 모듈로 분리할 수 있다.