도메인주도 설계 철저입문 -심효섭 옮김- [위키북스][DDD][책리뷰][6/7]

DDD의 전술 패턴에 집중한 책.

 

깔끔하고 좋았다.

---

요약 평가 [ 제목 2 ]

추천도 : 6/7

★★★★★★☆

 

읽은 기간 📅 : 2021년 8월 11일 ~ 2021년 9월 28일. [하루 30분]

 

이 책을 추천하는 이들 👨‍👧

• DDD에 관심이 있는 사람들. + 프로젝트 베이스의 설명 책을 찾는 사람들
• MSA에 관심이 있는 사람들

 

 

난이도 🦈

중 [ 웹 프로젝트의 구조 + 기본적인 프로그래밍 실력이 필요하다. ]

 

관련된 책들 📚

1. 도메인 주도 설계로 시작하는 마이크로 서비스 개발
2. 도메인 주도 설계 핵심 (에이콘)
3. 에릭 에반스의 DDD

 

한 줄 평 ✍️

현직 선배의 따듯한 조언들이 느껴졌던 책.

---

전략 VS 전술

 

DDD의 관점에는 크게 2가지가 존재한다.

 

도메인을 모델링하는 데 사용되는 전략(Strategy) 부분과 모델링으로 추출된 도메인을 실제 프로그램으로 전환하는 전술(Tactical) 파트.

 

전략은 더 큰 개념이고, 전술은 좀 더 세부적인 개념이다.

 

내가 교육받은 바로는 도메인 주도 설계의 저자 에릭 에반스는 자신의 책의 구조가 전략 -> 전술로 내용이 전개되는 것에 아쉬움을 느끼고 있다고 말했다.

 

자신이 정말 강조하고 싶은 부분은 현실 문제라는 복잡한 변화를 간직한 개념을 모델링하는데 도움이 될 수 있는 "전략"이었기 때문이다.

 

허나 책의 끝은 전술적인 파트로 끝을 맺게 되고

 

책을 다 읽은 독자로 하여금 전술에 대한 기억이 더 오래 강력하게 남게 되지 않을까 생각한 것이다.

 

전략적인 관점에서 DDD의 핵심은 도메인을 "증류"하고 프로토타이핑 하고 갈아엎은 다음 다시 정제된 도메인 모델을 개발하는 것이다.

 

그 과정에서 명확한 구분이 진행된 도메인 모델을 얻게 된다.

 

어떤 부분이 문제의 핵심인지, 어떤 부분이 부가적인 (서브)도메인인지, 인프라를 어떻게 사용하는 것이 좋은지

 

이것을 "컨택스트 맵"으로 추상적으로 관리하게 되고 각각의 도메인 하나의 서비스로 관리되면서

 

명료한 소프트웨어(생명체)의 구조가 잡히게 된다.

 

이 책에서도 마지막에 경량 DDD로 끝내지 말고 도메인 전문가와 함께 언어(사용되는 개념)들을 추출하고,

 

컨텍스트의 경계를 구분하고, 맵으로 만든 다음에 전술 DDD를 적용하라고 조언한다.

 

그런 점에서 이 책에는 "전략적인 파트"의 부재에 대한 아쉬움을 느낄 수 있다.

 

하지만 전략적인 부분이 이 책에서 한 번도 언급되지 않은 것은 아니다.

 

아키텍처, 소프트웨어 시스템 등에서 충분히 날카로운 의견들과 지식을 언급해준다.

 

---

전술적인 부분

 

엔티티, 값 객체, 리포지터리, 팩터리, 명세, 도메인 서비스, 애플리케이션 서비스, 애그리게이트 등등..

 

객체지향 개발론 서적을 읽으면 현실 객체를 어떠한 관점에서 이해해야 하는지 여러 도구들을 배워볼 수 있다.

 

이벤트(Event)

 

복잡한 시스템으로 구성된 개체들끼리 또 복잡한 시스템을 구성하는 것이 현실 세계이다.

 

그래서 현실세계는 상당히 복잡하다.

 

복잡한 관계가 다른 복잡하게 개체와 얽혀있기 때문이다. 어디가 이 복잡함의 끝인지 알 수 없게끔 가늠하기가 어렵다.

 

그리고 그 관계의 중심에는 "이벤트"가 있다.

 

이벤트는 교류이다. 살면서 우리는 무수히 많은 이벤트를 마주한다.

 

그 이벤트를 잘 들여다봐야만 이해관계자들. 즉 이벤트에 의존되어 있는 관계자(관계대상) 들을 살펴볼 수 있다.

 

언론에서 특정 사건을 탐사하고자 한다면 "돈의 흐름"을 파악하라는 말처럼,

 

도메인 모델링을 고민하는 사람은 이벤트의 흐름을 파악해야 한다.

 

이 이벤트에 관계된 대부분의 이해관계자들을 파악해야 한다.

 

그렇게 되면 우리는 이해관계자들이 가지고(혹은 고려하는) 있는 "역할", "책임", "규칙" 등등을 파악할 수 있다.

 

누가 가장 중요한 이해 관계자인지부터 이벤트에서 처리해야 하는 일들은 무엇인지,

 

그 과정에서 이해관계자들은 어떠한 책임을 가지고 어떠한 역할로 임하고 있는지.

 

이 과정에서 중요한 규칙들은 무엇이 있는지 (좀 더 넓게 보면 국가가 관리하는 법까지 개입될 수도 있다.) 

 

그렇게 차근차근 모델링을 해야 하는 범위를 측정해보게 된다. 

 

이 과정에서 우리가 얻은 정보들은 모델링에서 사용할 개념들이 된다.

 

그리고 개발자인 우리는 이 모델을 디지털 세계로 인도(통역) 해야 한다. 그리고 가치를 제공해야 한다.

 

역할은 엔티티가 되며

 

책임은 비즈니스 로직 혹은 명세 혹은 서비스가 된다.

 

그리고 이 과정에서 사용되는 측량 가능한 대부분의 설정값들은 값 객체라는 개념으로 치환된다.

 

그 과정에서 어디에도 속하기 애매하고 여러 객체들의 이벤트들을 관리해야 하는 경우는 애플리케이션 서비스로 따로 추출한다.

 

그리고 디지털 세계에서의 영속성을 관리하기 위해 리포지터리를 이용한다.

 

복잡한 객체는 엔티티를 입구로 둔 애그리게이트(집합)라는 개념으로 한 층 더 커지고, 복잡한 생성 메커니즘을 팩토리 패턴으로 다스린다.

 

전술적인 패턴이지만 다분하게도 전략적인 부분과 함께 일어난다.

 

이 책의 저자는 DDD를 상향식 접근(Bottom Up)으로 진행하라고 조언하는 부분도 여기에 있다.

 

그런 점에서 이 책은 정말 맛깔났다.

 

전술적인 부분으로 차근차근 DDD를 설명하는데 다 읽고 나서는 DDD의 전략적 설계도 머릿속에 들어있게 되니 말이다.

 

설명의 베이스가 되는 프로젝트가 C# 프로젝트라는 것이 아쉬웠지만

 

모델링 언어로써 Java와 매우 유사하기에 이해하는 데는 큰 어려움이 없었다.

 

오랜만에 깔끔하고 좋은 인사이트를 제공해 준 책을 읽어서 기분이 좋다.

---

위키북스 출판사.

-코드 컴플리트

-실용주의 사고와 학습

-오브젝트

-현재 읽고 있는 "도메인 주도 설계로 시작하는 마이크로 서비스 개발"

-도메인 주도 설계 철저 입문

 

명저들을 많이 번역(혹은 제작)해주는 고마운 출판사이다.

 

위의 책들은 나의 개인 개발 역량의 사고 범위를 확장시켜준 무서운 책들이었다.

 

좋은 책을 출판해주는 출판사. 정말 고맙다. 

 

좋은 책을 번역해준 심효섭 옮긴이와 책을 저술해주신 나루세 마사노부님께도 감사를 표한다.

---

책 속에 좋은 표현들

 

개발자는 소프트웨어 이용자의 세계를 이해할 수 있어야 한다.

소프트웨어 이용자에게 무엇이 중요한 지식인지는 바로 이 이용자의 세계에 따라 달라진다.

- 유용한 소프트웨어를 만들려면 이용자의 문제가 무엇인지 파악하고

- 이를 해결할 수 있는 최선의 수단을 생각해야 한다.

=> 도메인 주도 설계는 이러한 고찰을 반복하는 설계를 통해 이용자의 세계와 소프트웨어 구현을 연결 짓는 것이 그 목적이다.

 

 

소프트웨어의 목적 : 도메인에서 이용자들이 직면한 문제를 해결하는 것이다.

P4. 그렇다면 이용자들이 직면한 문제를 해결하려면 무엇이 필요할까? 말할 필요도 없이, 이용자들의 문제를 정확하게 이해하는 것이다.

- 이용자들이 어려움을 겪는 부분이 무엇이고 해결하고자 하는 문제가 무엇인지 알려면 이용자들의 관점이나 생각,

   그들이 처한 "환경"을 제대로 이해해야 한다.

⇒ 이용자의 도메인을 직접 경험해 봐야 한다.

 

 

현실과 소프트웨어는 시간이 지나면서 유지보수를 거치고 변경되기도 한다.

-도메인 객체가 도메인 모델을 충실히 반영하고, 유연성이 있는 구조를 갖춘다면 현실 도메인의 변화를 코드로 쉽게 옮겨낼 수도 있다.

도메인에 발생한 변화는 우선 도메인 모델로 전달되어야 한다.

 

 

값의 성질을 아는 것은 값 객체를 이해하기 위해 중요한 사항이다.

• 변하지 않는 성질
• 주고받을 수 있는 성질
• 등가성을 비교하는 성질

값 객체는 시스템 특유의 값에 대한 표현이며, 값의 한 종류이다.

=> 값의 성질은 값 객체에도 그대로 적용된다.

 

도메인 주도 설계 = 도메인에 주목하고 도메인 모델을 모델을 코드에 녹여내 도메인과 코드를 연결 짓는 개발 기법 

• 도메인 주도 설계는 특정 아키텍처를 전제로 두지 않는다.
• 도메인 주도 설계로 만들어진 소프트웨어는 이용자에게 지속해서 유용하기 위해선 끊임없는 개선을 버틸 수 있는 "구조"를 가져야 한다.

 

좋은 아키텍처 ⇒ 아키텍처는 지식을 표현한 코드를 적재적소에 배치하는 원칙이다.

• 아키텍처를 통해 도메인 규칙이 제자리를 벗어나는 것을 방지함과 동시에 한 곳에 모이게 할 수 있다.
• 도메인 주도 설계와 아키텍처가 떼려야 뗼 수 없는 주제인 것은 이 때문이다.

 

언어의 차이 = 생각의 차이 = 간극 = 소통의 불발 #keep [서로 간의 이해를 포기하게 되면 결국 도메인은 코드와 단절되는 결과를 낳게 된다]

서로 간의 이해를 포기하게 되면 결국 도메인은 코드와 단절되는 결과를 낳게 된다.

• 도메인의 개념이 왜곡돼도 이 단절 탓에 왜곡을 눈치채지 못하고 수정조차 불가능해진다.
• 제품의 코드는 개발자의 이해와 언어 위에 쌓아 올려지는 것이므로 소프트웨어가 엉뚱한 길로 나가게 된다.

 

도메인 전문가는 방대한 지식을 갖고 있지만, 그중 어떤 지식이 시스템에 유용할 것인지는 알지 못한다. #keep [ 이것을 알려면 시스템이 어떤 일을 할 수 있는지 이해해야 한다 ]

p327. 이것을 알려면 시스템이 어떤 일을 할 수 있는지 이해해야 한다.

• 그렇다고 개발자는 도메인 전문가의 말을 듣기만 해서도 안 된다.
• 개발자의 임무는 도메인 전문가와의 대화에서 시스템에 유용한 개념과 지식을 뽑아내는 것이다.

 

미묘한 언어의 차이(미묘한 개념의 차이)가 불러오는 작은 스트레스. 그리고 그 스트레스들이 낳는 오해들은 나중에 비용으로 돌아온다. #keep

P330. 서로의 언어를 변환하는 노력을 더욱 본질적인 곳에 집중할 수 있다면 더욱더 건설적인 결과를 얻을 수 있을 것이다.

개발자 간의 의사소통에도 공통의 언어를 사용하는 것이 바람직하다.

 

도메인 주도 설계의 목적 = 모델을 통해 도메인과 코드를 연결하고 이를 반복적으로 개선해 나가는 것 #Keep

P343. 도메인 주도 설계의 패턴을 맹목적으로 따르는 것이 아니다.