도메인 주도 설계 1부 독서 후기 (feat. DDD)
안녕하세요. yeTi입니다.
오늘은 도메인 주도 설계 의 1부의 읽은 후기를 기록하려고 합니다.
책을 선택한 이유
조영호님의 객체지향의 사실과 오해를 보면 도메인 모델을 기반으로한 객체 설계를 말합니다.
도메인 모델로 객체 지도를 만들어라.
그리고 JPA 의 repository 의 주석을 보면 DDD 에 의해 정의된 메카니즘이라고 표현합니다.
그렇게 DDD 를 읽기 시작했습니다.
현실의 복잡성을 풀어나가자
그런데 서문을 읽고 장황하게 설명된 표현들이 도메인 모델을 이해하고 현실의 복잡성을 풀어나가는것이 소프트웨어 개발의 본질이라고 말하는거 같습니다.
머릿속에서 명쾌하게 정리되는 느낌은 없지만 좋은 설계를 목표로, JPA가 지향하는 메카니즘을 이해하는 것을 목표로 읽어나가야 겠습니다.
지식을 보전하고 계승하자
도메인 주도 설계를 위함 첫걸음으로 지식 탐구를 말합니다.
폭포수 개발 방식은 피드백이 없어 실패합니다. 지식은 흘러갈 뿐 축적되지 않습니다. - p.14
업무 전문가 -> 분석가 -> 프로그래머로 전달되는 일방향적 지식의 흐름은 업무와 설계와 구현간의 피드백이 존재하지 않기 때문에 각자가 창의적으로 표현되는것을 막을 수 없습니다.
이렇게 만들어진 창의성은 서로간의 의사소통을 하는데 장벽이 될 수 있고 생산성을 저하시키며 신규 인력의 업무 적응력을 둔화 시킵니다.
업무 전문가 <-> 분석가 <-> 프로그래머로 이어지는 피드백 고리를 완성해야 의사소통 체계를 공유할 수 있고 지식 탐구 프로세스를 만들어갈 수 있습니다. - p.17
때문에 의사소통 체계를 공유해야 상호 이해할 수 있는 바탕이 만들어지며 그 바탕으로 지식을 쌓아가야 의도에 적합한 서비스를 만들 수 있습니다.
지식을 보전하고 공유하는데 도메인 모델과 그에 상응하는 설계를 이용할 수 있습니다. - p.20
나아가 지식을 보전하는 것이 중요한 이유는 현실의 복잡한 문제를 해결하기 위한 열쇠를 가질 수 있기 때문입니다.
도메인 모델과 코드로의 표현은 단지 클린 코드의 목표를 이루려는 것이 아니라 우리가 가진 지식을 보전하고 계승하기 위함입니다.
Ubiquitours Language로 간결하고 최신성의 맥락을 유지하자
우리는 현실의 복잡한 문제를 풀기위해 개발이라는 활동을 하고 현실의 복잡한 문제를 이해하기 위해 언어라는 도구로 소통이라는 활동을 합니다.
이 때 언어라는 도구를 사용함에 있어 각기 다른 의미를 가진다면 이해의 범주가 달라서 서로 다른 관점을 가질 수 있습니다.
번역은 의사소통을 무디게 하고 지식 탐구를 빈약하게 만든다. - p.25
이를 공통의 언어로 만들 수 있는것이 Ubiquitours Language 입니다.
Ubiquitours Language 를 기반으로 공통의 도메인을 정의하고 이를 중심으로 기술의 언어와 사용자의 언어로 확장해나간다면 오해를 방지할 수 있습니다.
Language 라는 특성은 동적인 형태로 지식을 전달함에 있기 때문에 다이어그램과 코드 이면에 존재하는 의미에 활력을 불어넣을 수 있습니다.
또한 언어로 표현함에 있어 장황하고 불명확하게 표현된다면 해당 개념 또한 모호함을 가진다고 볼 수 있습니다.
따라서 언어를 명확하게 구사한다는 것은 개념 또한 명확함을 가지게 됐다는 것을 의미합니다.
그리고 소통의 연장선상에서 다이어그램을 활용해야 합니다.
모델은 다이어그램이 아니라는 점을 명심해야 한다. - p.37
다이어그램은 모델을 설명하기 위한 수단일 뿐이고 코드가 설계의 실체입니다.
그러나 설계 문서로써의 코드 또한 맥락과 지침이 공유되지 않는다면 표현에 있어 한계를 가집니다.
그렇기 때문에 어느 정도는 글로 쓴 문서로 안정과 공유를 꾀할 필요가 있습니다.
이를 Ubiquitours Language를 구심점으로 문서와 프로젝트를 연결해서 최신의 유의미하고 간결한 맥락을 가져야 합니다.
모델, 설계, 코드는 상호 피드백을 주는 반복적인 과정이다.
소프트웨어 시스템에서 수행할 역할에 대해서는 전혀 고려하지 않은 채 업무 도메인의 개념만을 체계화 하려고 한다면 지식 탐구의 성과 중 대부분이 사라집니다.
즉 업무 도메인의 분석 결과물이 설계와 동떨어지는 경향이 있는데 이는 업무 도메인의 분석과 소프트웨어 시스템의 적용가능함이 일치하도록 풀어나가야합니다.
개발은 모델, 설계, 코드를 단일한 활동으로 정제하는 반복적인 과정이 된다. - p.50
많은 경우 코드를 작성하는 작업을 모델링하고 설계한 결과물을 옮기는 과정으로 인식합니다.
이러한 인식은 1장에서 언급한것과 같이 과거 폭포수 모델 방식에서 지식의 단방향 흐름에 따른 축적되지 않는 지식의 문제가 발생합니다.
따라서 코드를 작성하며 설계와 모델링에서 지속적으로 피드백하여 지식을 통합하고 축적시켜야 합니다.
DDD 의 키워드로 지식의 축적은 마음에 드는 문구입니다.
객체지향 프로그래밍은 모델링 패러다임에 근거하고 모델의 구성요소에 대한 구현을 제공하기 때문에 매우 효과적이다. - p.51
모델과 설계 간의 간극을 줄이려면 모델의 개념에 직접적으로 대응되는 소프트웨어 도구가 뒷받침되어야 합니다.
이를 가능하게 해주는 패러다임이 객체지향 프로그래밍(OOP) 입니다.
결국 업무 도메인과 소프트웨어 지식을 갖춰 모델을 생성하고 OOP을 적용하여 구현함과 동시에 모델을 지속적으로 정제해 나아가는 연계 작업을 해야합니다.
마무리
개발 활동에서 동떨어져 있던 문서와 모델과 설계와 구현을 연결시켜주는 느낌을 받았습니다.
1부를 읽음으로써 문서는 코드에서 표현할 수 없는 맥락과 지침을 공유하여 안정적인 체계를 갖춰나가는데 의미를 부여할 수 있고
문서 작성에 있어 고민인 최신성은 Ubiquitours Language 라는 공유된 맥락의 변경을 트리거로 활용하여 유지할 수 있다는 힌트를 받은거 같습니다.
그리고 역시나 모델과 설계는 구현으로부터 지속적인 피드백을 받아 같이 성장해나가야지만 쓰임새를 가질 수 있다는 것을 다시 한번 느낍니다.
중요한 것은 협업을 함에 있어 언어라는 도구를 사용하기 때문에 언어가 가지는 경험의 차이를 극복하기 위해서 맥락을 맞춰나가는 작업이 필요합니다.