도메인 주도 설계

꽤 오래전에 읽은 책이 eBook으로 새로 출간되었다. 2011년에 번역서가 나왔었는데, 2023년에 eBook으로 출간되었다. 꽤 어렵게 읽었던 기억이 있어서 다시 읽어보려고 구매했다. 개정판인가 기대를 살짝 했었는데 개정판은 아니다.
출간된 지 10년이 훌쩍 넘은 기술 서적이지만 지금 읽어도 좋은 책이다.

도메인 주도 설계의 목표는 기술보다는 도메인에 대한 모델에 집중해 더 나은 소프트웨어를 만들어내는 것이다.

이 책의 목표를 간결하게 보여주는 멋진 말이다.

상호의존성은 모델과 설계를 이해하기 어렵게 만든다. 또한 테스트를 어렵게 만들고 유지보수성을 떨어뜨린다. 그리고 쉽게 축적되는 경향이 있다.
...
객체 개념을 구성하는 데 필수적이라는 사실이 증명되기 전까지는 모든 의존성을 검토해야 한다. 이러한 검토 과정은 모델 개념 자체를 분해하는 것에서 출발한다. 그런 다음 개별 연관관계와 연산에 주목해야 한다. 모델과 설계와 관련된 결정을 하면서 의존성을 조금씩 없앨 수 있으며 가끔은 의존성을 완전히 제거할 수 있다.

이 책에서 소개하는 여러 가지 개념들은 결국, 의존성을 식별하고 분리하여 복잡도를 관리하기 위한 것이라고 생각한다. 

 

다시 읽어보니, 왜 어렵게 읽었었는지 기억이 났다. 워낙 유명한 책이지만 내용의 쉽고, 어려움을 떠나서 가독성이 매우 안 좋다. 다른 DDD 개론서와 같이 보기를 추천한다. 우리말인데 읽어도 무슨 말인지 모를 문장들이 종종 등장한다. 기술 서적에서 필요 이상으로 말을 멋있게 쓴 원문에도 문제가 있다고 생각하지만, 번역도 애매한 부분이 있다. 책의 후반부로 갈수록 더 그런 것 같다.

대규모 구조는 어떤 구조가 모델을 개발하는 데 부자연스러운 제약조건을 강제하지 않고도 시스템을 굉장히 명확하게 만드는 것으로 판명될 때 적용해야 한다. 맞지 않는 구조는 차라리 없느니만 못하므로 종합적인 구조를 얻으려 애쓰기보다는 발생한 문제를 해결하는 최소한의 집합을 찾는 편이 가장 낫다. 적을수록 더 많은 법이다.

‘적을수록 더 많은 법이다.’ 이게 무슨 말인가? 문맥상 '과유불급' 느낌이라 ’적을 수록 좋다.‘ 정도 같은데, 원문에 뭐라고 적혔기에 이런 문장인가 해서 찾아봤다. ‘Less is more.’ 이걸 번역기랑 똑같이 직역을 하면… 이렇게 번역에 아쉬운 부분이 여기저기 좀 있다. 

 

문장도 문장이지만, 어떤 기술 용어는 한글로 표기하고 어떤 기술 용어는 영문으로만 표기하여 때때로 영어 사전으로 단어를 찾아보는 불편함이 있다. 예를 들어 디스틸레이션은 한글로 적었고, cohesive는 영문으로 적고 있으며, context와 컨텍스트로 영문, 한글을 혼용해서 사용하는 등 일관성이 없다.

 

한번 읽고서 바로 실무에 적용하기는 어렵고, DDD가 마법의 단어는 아니니 적용하려는 프로젝트의 성격에 따라 적용 범위를 조율하는 것이 좋다고 생각한다.

 

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=307913446 

[전자책] 도메인 주도 설계

모든 소프트웨어 프로그램은 그 소프트웨어를 사용하는 사용자의 활동이나 관심사와 관련돼 있다. 사용자가 프로그램을 사용하는 대상 영역이 바로 해당 소프트웨어의 도메인(domain)이다. 
...
모든 프로젝트에서는 지식이 새기 마련이다. 뭔가를 학습한 사람들은 계속 자리를 옮긴다. 조직 개편으로 팀이 흩어지고 지식도 다시 여기저기로 흩어진다. 중대한 하위 시스템은 외주 제작되어 코드는 전달되지만 지식은 전달되지 않는다. 그리고 전형적인 설계 방법으로는 이렇게 힘겹게 알아낸 지식이 코드와 문서에서 유용한 형태로 표현되지 못하므로 어떠한 이유로든 구두로 전달하기가 어려워지면 지식은 사라진다.
...
객체 모델이 지나치게 완전해지는 까닭은 사람들이 앞으로 코딩할 것들을 모조리 모델링 툴에 집어넣어야 한다고 생각하기 때문이다. 이러한 모든 세부사항이 존재하는 상황에서는 어느 누구도 나무만 보고 숲은 보지 못한다.
...
순수하게 이론에만 치우친 분석 모델은 심지어 도메인의 이해라는 가장 주된 목표에 미치지 못하기도 하는데, 중요한 발견은 언제나 설계/구현을 위해 노력하는 가운데 나타나기 때문이다. 매우 특이하고 미처 예상치 못한 문제는 늘 일어나게 마련이다. 선행 모델은 중요한 주제는 간과하는 반면 그다지 관련 없는 주제는 깊이 있게 다룰 것이다.
...
매우 복잡한 작업을 처리하는 소프트웨어를 만들 경우 관심사의 분리(separation of concern)가 필요하며, 이로써 격리된 상태에 있는 각 설계 요소에 집중할 수 있다. 동시에 시스템 내의 정교한 상호작용은 그러한 분리와는 상관없이 유지돼야 한다.
...
당연히 각 계층은 서로 연결돼야 한다. 분리의 이점을 잃지 않으면서 각 계층을 서로 연결하는 것이야말로 각종 패턴이 존재하는 이유다.각 계층은 설계 의존성을 오직 한 방향으로만 둬서 느슨하게 결합된다.
...
여러 도메인 측면 중에는 객체보다는 행동(action)이나 연산(operation)으로 좀더 명확하게 표현되는 것도 있다. 비록 이러한 측면이 전통적인 객체지향 모델링에서 다소 벗어나긴 하지만 어떤 연산의 책임을 특정 ENTITY나 VALUE OBJECT에서 억지로 맡기보다는 SERVICE로 표현하는 편이 나을 때가 있다.
...
MODULE로 쪼개지는 것은 코드가 아닌 바로 개념이다. 어떤 사람이 한 번에 생각해낼 수 양에는 한계가 있으며(따라서 결합도는 낮춰야 한다), 일관성이 없는 단편적인 생각은 획일적인 생각을 섞어놓은 것처럼 이해하기 어렵다(따라서 응집도는 높여야 한다).
...
순환 참조는 논리적으로 여러 도메인에 존재하며 간혹 설계에도 필요하지만 순환 참조를 유지하는 데는 신중을 기해야 한다. 동기화를 유지해야 하는 두 곳에서 동일한 정보를 보관하지 않는 식으로 구현 선택에 도움을 줄 수 있다.
...
리팩터링은 엔트로피와의 싸움이며 레거시 시스템이 퇴보하는 것을 막는 최전선에 놓여 있다. 하지만 가장 중요한 통찰력은 어느 순간 갑자기 떠오르고 그에 따른 충격은 프로젝트 전체로 퍼져나간다.
...
구현을 인터페이스로부터 분리하면 어떤 구현이라도 프로젝트가 병렬로 진행될 수 있는 유연성을 제공할 수 있다. 적당한 시기가 되면 좀더 효과적인 구현으로 프로토타입을 대체할 수 있다. 그전까지 시스템의 모든 다른 부분은 개발 단계 동안 상호작용할 수 있는 대상을 갖게 된다.
...
모든 것이 순조롭다. 누군가가 규칙을 변경하기 전까지는…….
...
전체 설계 영역을 동시에 다룰 수는 없다. 조금씩 뜯어내야 한다.
...
변경을 완벽하게 정당화할 수 있을 때까지 기다린다면 지나치게 오랫동안 기다린 셈이다. 프로젝트는 이미 과다한 비용 손실을 초래하고 있으며 변경을 미룰수록 변경하려는 코드가 더 복잡해지고 해당 부분을 사용하는 코드도 늘어나기 때문에 변경하기가 더 어려워질 것이다.
...
이해하기 힘든 시스템은 변경하기도 어렵다. 아울러 변경의 효과도 예측하기 어렵다.
...
어떻게 해서든 고유한 소프트웨어를 개발하는 일은 결국 전문지식을 축적하고 지식을 면밀히 검토해서 풍성한 모델을 만들어내는 안정화된 팀에서 해야 할 일이다. 지름길은 없다. 마법의 탄환도 없다.

-알라딘 eBook <도메인 주도 설계> (에릭 에반스 지음, 이대엽 옮김) 중에서