도메인 주도 설계란 무엇인가? 2주차 - 권태형

2025/Domain-Driven Design Quickly/taehyoung/4.md

@@ -0,0 +1,28 @@
+# 4장 깊은 통찰을 향한 리팩토링
+
+# 논의 내용
+
+논의 내용에 대한 배경 설명
+- 책에서 모델을 계속 해서 개선(refactor) 해야 한다 라는 말에 고개를 끄덕이면서도, 실제로 제가 회사에서 어떻게 하고 있나를 생각 해보았을 때, 결론은 **초반에만** 도메인 전문가로 부터 지식을 끄집어 내어 나름의 모델링을 한다는 것입니다. 즉 초반에 요구사항을 정의할 때, 잠깐동안만 도메인 전문가의 암묵적 지식을 명시적 지식으로 모델에 반영하는 것이지요. 결국에 시간이 지나면, 더이상 모델을 개선(refactor)는 하지 않고, 도메인 전문가와 구성원들은 다시 암묵적 지식으로 가지게 된다는 것 입니다. 이는 코드와 일치하지않는 deprecated된 위키문서, 기획서 등을 통해서도 흔히 볼 수 있습니다.
+
+즉, 모델을 개선(refactor) 하지 않는 다는 말은 도메인과 관련된 구성원들이 가지는 암묵적 지식이 늘어난다는 말과도 동일하다고 볼 수 있을 것 같습니다. 그래서, 새로운 팀원이 온보딩을 해야할 때, 기존의 문서 혹은 코드와 더불어서, 해당 도메인의 담당자와 질문과 답변 과정을 또 거쳐야할 수밖에 없고 이는 계속적으로 반복되는것 같습니다. 이론적으로 보면, 도메인과 관련된 구성원들의 암묵적 지식들이 도메인 모델에 모두 반영이 되어있다면, 해당 도메인을 모르는 사람도, 도메인 모델만 보고도 이해할 수 있어야 하는데, 현실적으로는 이 도메인 모델이 잘 관리되지 않다보니, 암묵적 지식이 어쩔 수 없이 계속 생기게 되는 것 같습니다
+
+논의 내용
+1. 도메인 모델에 구성원들의 암묵적 지식을 모두 명시적으로 반영할 수 있도록 하는, 구체적인 방법이 있다면 어떤 것이 있을까요? 현실적이지 않은 방법이라도 본인이 생각하는 방법이 있다면 아이디어를 내서, 얘기해보면 좋을것 같습니다
+2. 위의 1번 에서 고민해본 방법이 현실적일 수도, 현실적이지 않을 수도 있을 것 같습니다. 현실적으로 가능하다면, 혹은 현실적으로 불가능하다면, 왜 그렇게 생각하는지 같이 얘기 나눠보면 좋을것 같습니다
+
+# 키워드
+
+1. 리팩터링
+2. 불변식(Invariant)
+3. 제약조건(Constraint)
+4. 처리(Process)
+5. 명세(Specification)
+
+# 내 생각
+
+- 이 장에서 나오는 리팩토링의 의미는 단순히 마틴 파울러의 저서인 리팩토링에서 말하는 코드 레벨의 리팩토링 만을 말하진 않는 것으로 보인다. 단순히 코드 레벨에서의 리팩토링이 아닌, 더 큰 범위에서의 리팩토링을 말하고 있다. 회사에서 일을 할 때, 구성원들 끼리의 소통의 원천은 DDD의 맥락에선 모델 입니다. 모델 또한 리팩토링의 대상이다. 책에서는 개선의 의미에서의 refactor 라는 단어로 표현을 하고 있다 구체적으로는 암시적 개념들을 명시적으로 만들기위해서, 도메인 전문가와 지속적인 대화를 할 수 도 있을 것이고, 그 과정에서 만들어진 지식의 체계에 모순점이 생길 수 있는데, 이것을 바로잡는 것도 그 사례일 수 있을 것이고, 누락된 개념을 발견하고 이를 추가하는 것도 사례일 수 있을 것 이다. 이러한 과정을 거침으로써, 모델은 개선 될 것이고, 도메인 전문가, 개발자, PO의 멘탈모델이 이 모델에 그대로 투영될 수 있다면, 무결성을 가진 모델을 작성하는 그 목표를 달성할 수 있을 거라고 생각한다
+- 책에서 암시적인 것을 명시적으로 나타내는 방법으로 제약조건(constraint), 절차(process), 명세(specification)을 말하고 있는데, 실제로 개인적으로 도메인 분석에서 사용하고 있는 방식이다 내 개인적으로는 문.해.조.절.검 의 형태로 정의해서 사용하고 있다
+- 제약조건(Constraint)와 불변식(Invariant) 용어 간에 어떤 상관관계가 있고 어떻게 다른지 궁금했었는데, 제약조건은 불변식을 실현하기 위한 수단이고, 불변식의 구체적인 것이 제약조건 임을 알게 되었다
+- 이 장을 읽으면서, 설계에 대해서도 어떻게 정의를 해야할지를 다시 고민하게 되는 계기가 되었다 설계는 유연해야한다 라는 문장을 보고 애초에 설계라는 작업은 유연성과 확장성을 어떻게 고려해서 가져갈것인가에 대한 고민의 과정과 적용의 결과가 아닐까? 라는 생각이 들었다
+- 개인적으로 5장에 나오는 분할된 컨텍스트를 어떻게 나눌 것인가와 더불어서, DDD의 핵심은 도메인 전문가의 머릿속에만 있는 암시적 개념을 어떻게 끄집어 내서, 명시적인 모델로 만들 것인가? 라고 생각한다

2025/Domain-Driven Design Quickly/taehyoung/5.md

@@ -0,0 +1,30 @@
+# 5장 모델 무결성 보존
+
+# 논의 내용
+
+1. 본인 혹은 회사에서 이런 분할된 컨텍스트를 정의해본 경험이 있다면 같이 얘기해보면 좋을 것 같습니다
+   - 책에 분할된 컨텍스트를 나눠야한다는 말은 나옵니다. 하지만, 어떤 방식으로, 어떻게 나눠야한다는 말은 나오지 않습니다. 개인적으로 어떻게 나눠야한다는 내용이 나오지 않는 이유는 나누는 방법에 정답이 존재하지 않기 때문이 아닌가라는 생각입니다. 
+   - 즉, 각 개인과 조직 마다 상황에 따라서 적절히 나누면 되는 것이라는 뜻 입니다. 실제로 저희 회사에서도 마이크로서비스를 정의할 때, 어떤 구체적인 방법을 사용하지 않습니다. 어떻게 나누는게 좋을지에 대해서 구성원들 간의 토론을 통해서, 컨텍스트 경계의 범위가 적절한지를 결정하고 있습니다
+
+# 키워드
+
+1. 컨텍스트
+2. 분할된 컨텍스트
+3. 지속적인 통합
+4. 컨텍스트 맵
+5. 공유커널
+6. 고객-공급자
+7. 순응
+8. 변질방지레이어
+9. 분할방식
+10. 오픈 호스트 서비스
+11. 증류
+
+# 내 생각
+
+1. 5장에 오기 전까지는 모델의 크기가 매우 크다는 전제를 하지 않은 상태라고 봐야할 것이다. 5장에서는 이 모델의 크기가 매우 크다는 전제하에서, 어떻게 모델의 무결성을 관리할 것인지에 대한 이야기를 전개해나간다
+2. 여기서 중요한 것은 매우 큰 모델을 어떻게 나눌 것인가 라는 것이다. 이를 설명하기 위해서, 분할된 컨텍스트 라는 개념이 나오게 된다 분할된 컨텍스트는 도메인 모델이 적용되는 개념적인 경계로 말할 수 있는데, 어떤 기준을 가지고, 개념적으로 도메인을 분리해서 정의한 것으로 볼 수 있다. 분할된 컨텍스트를 좀 더 큰 범위에서 보면, 회사에서 도메인 별로 팀을 나눌 때, 모놀리식 서비스에서 마이크로서비스를 분리 할 때, 모두 분할된 컨텍스트의 맥락하에서 이해 해볼 수 있다
+3. 그 다음으로 나오는 내용들은 분할된 컨텍스트 간의 관계를 어떻게 설정할 것인가에 대한 것이다 이부분은 추상적인 개념으로 이해하기 보다도, 위에서 말한 것 처럼 실제 회사에서 팀을 어떤 기준으로 나누고, 팀 간의 관계를 어떻게 정의하는지, 마이크로서비스를 분리하고, 각 마이크로서비스 간에 어떤 관계를 정의하는지와 같은 구체적인 사례들을 기준으로 보면 훨씬 더 이해하기가 쉽다
+4. 위 관점에서 보면, 분할된 컨텍스트의 관계에 관련된 키워드들은 전혀 어렵지 않고, 지극히 상식적인 이야기 임을 알 수 있다. 그리고 흔히 많은 사람들이 말하는 DDD가 단순히 엔티티, 리파지토리 등등의 전술적 설계에서의 빌딩블록들을 다루는 것 이상으로 코드 자체가 아닌, 실생활에 더 밀접하게 연관된 것임을 알 수 있다. 개인적으로는 회사에서 실용적으로 DDD를 활용하고자 한다면, 분할된 컨텍스트를 어떻게 나눌 것이고, 그중에서도 핵심 도메인과, 서브 도메인은 어떻게 나눌 것인지, 분할된 컨텍스트 간의 관계를 어떻게 정의하고 운영할것인가, 분할된 컨텍스트 하의 모델들의 유비쿼터스 언어를 관리하고, 모델의 무결성이 없도록 할지에 대해서 더 집중하는게 좋다고 생각하고, 이게 DDD의 더 핵심적인 부분이라고 생각한다. 이를 전략적 설계라고 하고, 전술적 설계는 전략적 설계가 전제된 상태에서 고려되어야한다고 생각한다
+5. 이처럼 DDD의 전략적 설계는 코드 이상으로, 더 큰 범위에서 사용이 될 수 있다. 회사를 기준으론 어떻게 팀을 나눌지, 핵심 팀과 서브 팀은 어떻게 되는지, 이 팀들을 어떤 기준으로 나누고, 관계를 설정할지 등등 이와 관련해서는 [팀토폴로지](https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=258906450) 라는 책을 보면 관련된 인사이트를 얻을 수 있다
+6. 마이크로서비스를 기준으로 보면, DDD에서 분할된 컨텍스트를 나누는 기준으로 마이크로서비스를 나눌 수 있다. 실제로 마이크로서비스 패턴 책을 비롯한 마이크로서비스 관련된 책이나 아티클을 보면, DDD의 분할된 컨텍스트 얘기가 나오는 것을 알 수 있다.

2025/Domain-Driven Design Quickly/taehyoung/6.md

@@ -0,0 +1,15 @@
+# 6장 오늘날 DDD는 중요하다
+
+# 논의 내용
+
+1. 6장 제목은 오늘날 DDD는 중요하다 입니다. 이번에 DDD 책을 읽고, DDD가 중요하다고 느끼셨나요? 
+    - 일단 저는 DDD 자체가 별로 중요하다고는 생각진 않습니다. 쉽게 말하면, 몰라도 된다고 생각 합니다. 짧은 경험이지만, 회사에서 DDD에서 말하는 개념과 키워드들을 몰랐었도 일을 하는데 전혀 문제가 없었기 때문입니다. 이것은 저를 제외하고도 다른 분들도 마찬가지 였습니다 어떻게 보면 DDD에서 하는 말들이 전부 상식적인 말들이기 때문에 굳이 이걸 이론적으로 정리하지 않아도, 회사 구성원들끼리 합리적인 결정을 위한 토론과 논의 과정에서 무의식적으로 적용하게 되었기 때문이 아닐까 생각됩니다.
+    - 오히려, 이번에 DDD를 배웠다고 해서, 무리하게 회사에서 팀원들을 설득하려고 하는게 더 위험한 행동이 아닐까 라는 생각을 해봅니다. 굳이 필요없는 것을 내가 봤을 때 좋아 보인다고, 적용하는 것은 이기적인게 아닌가 라는 생각이 듭니다
+    - 다만, DDD에서 배운 키워드들과 개념들은 제 개인적으로 도움이 많이 되었다고 생각합니다 이정도로 저는 매우 만족스럽습니다
+
+# 내 생각
+
+1. 책 맨 뒤에 나오는 저자의 조언이 어찌 보면, 책의 가장 앞에 있어야 하는 내용이 아닐까 생각된다 그 이유는 많은 사람들이 DDD를 거론 할 때, 이 조언들에 대한 고려 없이 말을 하는 것 같다 라는 느낌을 받았기 때문이다. 특히, 3번 DDD를 모든 것에 적용하려고 하지 마세요 와 4번 실험을 많이하고 실수를 많이 할 것이라고 예상하세요. 모델링은 창조적인 작업입니다 에 대해서는 별로 고려하지 않는 것 같다(개인적인 생각)
+2. 아무튼 DDD 책을 읽으면서, 나 스스로 책의 내용들을 어떻게 현실세계에 반영해서 활용할 것인가에 대해서 고민을 많이 하였고, 실제로 많은 힌트를 주었다고 생각해서 도움이 많이 되었다고 말할 수 있을 것 같다. 다만, DDD 또한 은탄환이 아니기 때문에, 여기에 맹목적으로 의존하는 것은 옳지 않다는 생각이다
+3. 이 책을 통해서 알 수 있는 것은 DDD가 단순히 코드 레벨에서의 코드 설계에 머물지 않는 다는 점이다. 오히려 코드 부분은 책에서도 총 1~5 장 중에 3장에서만 언급이 된다. 이는 사실 에릭 에반스가 쓴 DDD 책에서도 마찬가지이다. 이와 반대로, 시중에 나와있는 DDD start 라는 최범균님이 쓴 책을 보면, 코드레벨에서의 DDD를 주되게 다룬다. 이것을 딱히 틀렸다고 말할 순 없지만, 상대적으로 에릭 에반스의 책은 어렵기 때문에 사람들이 읽기를 꺼리는 중에, DDD start는 더 많이 보는 경향이 있는데, 그 책 한권만 봄으로써, 실제 창시자가 말하는 핵심과 동떨어진 내용을 핵심으로 생각하고 전파하는 경우를 봤다. 아쉽다는 생각이들었고, 그 사람들에게 어떻게 설명해줘야하나에 대해서 고민이 있었는데, 이 DDD quickly 책을 보여주면 되겠다 라는 생각이 확실히 가질 수 있게 되었다
+4. 이 책은 다른 수많은 DDD 책들 대비해서, DDD의 핵심적인 내용을 매우 잘 드러내고 있는 좋은 책이라고 생각한다 이번에 책을 읽기 전에도 물론, 몇번을 읽었지만, 이번에 한번 더 정독하면서 읽으면서, DDD에 대해서 더 많이 고민을 하게 된 계기가 되어서 좋았고, DDD에 대한 통찰력이 이전보다 확실히 더 발전했다는 생각이든다 이를 시작으로, 다른 DDD 관련된 책도 다시 보면서, 내 기준에서의 DDD를 정의하고 현실에서도 많이 적용해보면 좋을 것 같다는 생각이 든다