도메인 주도 설계 철저 입문 1장을 읽고 요약한 내용입니다.
1. 도메인 주도 설계란?
1.1 도메인 주도 설계란 무엇인가?
소프트웨어를 개발하다 보면 새로운 분야를 익히게 된다. 예를 들어 회계 시스템을 개발할 때는 경리 업무에 대해 배우게 되고, 물류 시스템을 개발할 때는 수송이나 배송 과정에 대해 배운다.
이용자에게 유용한 소프트웨어르 개발하려면 가치 있는 지식과 그렇지 않은 지식을 신중하게 구분해서 가치 있는 지식만 코드에 녹여 넣어야 한다.
유용한 소프트웨어를 만들려면 이용자의 문제가 무엇인지 파악하고, 이를 해결할 수 있는 최선의 수단을 생각해야 한다. 도멩니 주도 설계는 이러한 고찰을 반복하는 설계를 통해 이용자의 세계와 소프트웨어 구현을 연결 짓는 것이 목적이다.
1.2 도메인 지식에 초점을 맞춤 설계 기법
제목을 보면 '도메인이란 무엇인가?'라는 의문이 생길 것이다. 도메인은 영역이라는 뜻이다. 특히 개발에서 도메인은 '프로그램이 쓰이는 대상 분야'라는 의미로 쓰인다.
회계 시스템을 다시 예로 들면 금정 혹은 장부와 같은 개념이 등장한다. 이 개념은 회계 시스템의 도메인에 속한다. 이렇듯 도메인에 포함되는 개념은 시스템의 대상 분야가 무엇인지에 따라 크게 달라진다.
소프트웨어의 목적은 도메인에서 이용자들이 직면한 문제를 해결하는 것이다. 이 문제를 해결 하기 위한 것은 '이용자들이 문제를 정확히 이해하는 것'이다. 이용자들이 어려움을 겪는 부분은 무엇이고 해결하고자 하는 문제가 무엇인지 알려면 이용자들의 관점이나 생각, 그들이 처한 환경을 제대로 이해해야 한다.
1.2.1 도메인 모델링이란 무엇인가?
모델은 현실에 일어나는 사건 혹은 개념을 추상화한 개념이다. 추상이란 여러 사물 혹은 개념에서 공통적인 것을 뽑아 파악하는 것으로, 현실의 모든 것을 반영하는 것이 아니다. 상황에 따라 취사 선택이 필요하다.
펜을 예로 든다면 어떤 성질을 뽑아내야 할까? 소설가의 관점에서 본 펜은 도구이며, 글자를 쓸수 있다는것은 중요한 성질이지만, 문구점의 관점에서 본 펜은 상품이며 글자를 쓸수 있는 기능 보단 상품으로서의 가치가 더 중요하다. 이를 통해 알 수 있는 것은 같은 대상이라도 중점이 달라질수 있다는 점이다.
1.2.2 지식을 코드로 나타내는 도메인 객체
소프트웨어 이용자가 처한 세계는 항상 같은 상태로만 존재하지 않는다. 사람이 하는일은 바뀌기 쉽고, 시간에 따라 변화하기 쉽다.도메인 객체가 도메인 모델을 충실히 반영하고 있다면 도메인의 변화를 코드로 쉽게 옮길 수 있다.
1.3 이 책의 접근법과 목표
지식은 연쇄적으로 연결돼 있다. 어떤 짓식을 이해하려면 그 전제가 되는 다른 지식이 필요한 경우가 많다. 도메인 주도 설계와 관련된 개념을 이해하려면 더 많은 배경지식이 필요하다.
또 큰 문제점은 도메인 주도 설계의 프랙티스 자체에 애초 실천하기 어려운 것이 있다는 점이다.
도메인 주도 설계라는 주제는 구현뿐만 아니라 개발 관계자들 사이의 커뮤니케이션이나 팀 빌딩과도 밀접한 관계가 있다. 다시 말하면 개발자 개인 외에도 수많은 관계자가 엮여 있다는 말이다. 이상을 좇되, 현실과 타협해야 하는 상황에 어느 부분에서 타협할 것인가를 고민하는 것도 소프트웨어 개발의 즐거움중 하나다. 혹여 독자 여러분이 도메인 주도 설계의 모든 것을 실천 할 수 있는 환경에 있지 못하더라도 더 많은 배움을 얻기 위해 도메인 주도 설계를 선택한 것은 옳은 선택이다.
1.4 이 책에서 설명하는 패턴에 대하여
목적지를 모른채 길을 나서는 것은 마치 미로를 헤메는 것과 같다.
- 지식 표현을 위한 패턴
값 객체 (VO)
엔티티
도메인 서비스 - 애플리케이션을 구성하는 패턴
리포지토리
애플리케이션 서비스
팩토리 - 지식 표현을 위한 고급 패턴
애그리게이트
명세
왜 지금 도메인 주도 설계가 필요한가?
도메인 주도 설계의 개념은 2004년에 처음 등장했다. 하지만 종전에는 서비스를 하루라도 빨리 출시하는 것이 가장 중요시 됐다. 그러니 모델링에 중점을 두어 개발 극초기에 비용이 들어가는 도메인 주도 설계는 기만하지 못한 개발 기법으로 오해를 받고 기피하게 됐다.
서비스를 빠르게 출시하는 것은 편도 행 로켓에 타는 것과 비슷하다. 일단 발사 후에는 돌아올 수 없다는 단점을 제외하면 시스템 개발 업종의 가혹한 생존경쟁에서 살아남을 수 있는 최선의 선택지이기도 하다. 이와 달리 꼼꼼하 모델링은 항공기를 운항하는 것과 비슷하다고 볼 수 있다.
소프트웨어는 항상 진화하는 존재다. 개발 극초기 잠깐 동안의 개발 속도를 우선시한 소프트웨어는 유연성이 떨어지며 변화에 대응하기 어렵다. 소프트웨어가 변화에 제대로 대응하려면 개발자가 지속해서 소프트웨어를 수정해야 한다. 이렇게 여러해가 지나다 보면 소프트웨어는 복잡하고 이리저리 기워진 누더기가 되기 일쑤다. 편도 로켓 발사 대신 안정적인 항공기 운항을 원하게 됐다는 것도 이런 땜질식 수정 업무에 질렸다고 생각하면 어느 정도 이해가 간다.
도메인 주도 설계의 진정한 가치가 드러나는 것은 변화에 대응해 소프트웨어를 수정할 때다.
지금 당장 동작하는 프로그램을 만드는 것은 어렵지 않다. 그러나 앞으로도 계속 동작할 프로그램을 만들기는 어렵다.다시 말해 로켓 대신 항공기 같은 안정적인 운항을 원한다면 도메인 주도 설계를 익혀야 한다.
