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

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

@@ -0,0 +1,26 @@
+# 1장 도메인 주도 설계란 무엇인가?
+
+# 논의 내용
+
+1. 개인적으로는 단순히 UML 혹은 다이어그램으로 표현되는 단순한 형태의 도식화된 그림 만으로는, 도메인 모델로써 확실히 부족한 면이 있다고 생각하는 편 입니다. 디테일한 세부사항까지는 커버하기 힘들기 때문 입니다. 그래서 최근에 제가 생각하고 있는 것은 대략적인 도메인의 큰 그림을 보여줄 수 있는 도메인을 표현한 다이어그램, UML 등과 함께 세부사항이 적힌 정책서 두가지를, 유지보수가 반드시 필요한 모델로 지정하고, 적용해보고 있는 중 입니다. 책을 읽으면서, 혹은 업무를 하면서, 현실에 적용이 가능하다는 전제하에, 본인이 생각한 모델의 구체적인 사례가 있다면 얘기해보면 좋을 것 같습니다
+
+2. 업무할 때, 사용하고 있는 구체적인 도메인 모델이 있다는 가정하에(아마도 대개의 경우는 도메인을 정리하고 표현하기 위한 사내 위키문서, 기획서 등등 있지 않을까 생각됩니다), 그 도메인 모델의 유지보수는 실제로 어떻게 하고 있는지 얘기해보면 좋을 것 같습니다
+
+# 키워드
+
+1. 도메인
+2. 모델링
+3. 도메인 모델
+4. 추상화
+5. 도메인 지식
+6. 도메인 개념
+
+# 내 생각
+
+1. 우리의 목표가 소프트웨어 개발을 통한 현실세계 문제를 푸는 것이라면, 코드 자체에 매몰 되어선 안된다. 물론 이 말이 코드가 중요하지 않다는 의미는 아니다. 다만, 목표가 현실세계 문제를 푸는 것이라면, 그 자체에 더 집중해야 한다는 말이다 그런 의미에서 도메인 주도 설계는 그 구체적인 방법론으로 볼 수 있다
+    1. 예를들어서, 소프트웨어 개발 자체가 현실세계에서 발생하는 문제를 푸는게 아니라, 더 하위의 엔지니어링 적인 문제를 푸는것 자체가 목적이라면, 코드 그 자체에 좀 더 집중해야할 수도 있을 것이다 즉, 목표가 무엇이냐에 따라 다르다고 말할 수 있다
+2. 책에서는 소프트웨어를 만들 때, 도메인을 모델링 해야한다고 말한다 이렇게 해야하는 이유는 도메인을 기준으로, 다른 직군간(개발자, PO, 도메인 전문가 등등)의 소통을 통해서 소프트웨어가 만들어지기 때문이다. 그래서 각 직군 간에, 소통을 할 도구가 필요한 것이고, 도메인 전문가가 가지고 있는 지식과 코드가 최대한 일치되게 하기 위한 중간 소통 도구로써, 도메인 모델이 중요하다 도메인 모델이 제대로 만들어지지 않아서, 각 직군 간에 소통의 오류가 생긴다면, 이는 곧 소프트웨어의 버그로 이어지게 될 것이다
+3. 도메인 모델은 도메인 자체를 이해하는데 큰 도움을 주도록 하는 것을 목표로 한다 그래서 적절한 추상화를 통해서, 꼭 필요한 부분에 대해서만 추려서 이해하기 쉽게 만들게 되고, 이 모델을 어떤 직군의 사람이 와도 이해할 수 있어야 한다
+4. 도메인 모델을 만들어 나가는 과정은 도메인 전문가의 머릿속에 암묵적으로 존재하는 지식들을 밖으로 꺼내어 타 직군 사람들도 도메인 지식을 습득하고 이해하는데 도움이 되도록 하는 것을 목표로 한다 그래서 도메인 모델을 만드는 과정에서 도메인 전문가와 같이 대화를 하면서, 이것들을 잘 정리해야할 필요가 있다
+    1. 책에 `겉으로 보기에 무질서해 보이는 이 수많은 정보 안에서 규칙을 찾아내려면 ...`  이라는 말이 나오는데, 맥락상 도메인 모델을 만드는 과정을 설명하는 것으로 볼 수 있다. 이러한 규칙과 패턴을 찾아서 모든 사람들이 이해할 수 있는 도메인 모델링을 만들 수 있는 것이 개발자의 역량이라고 생각한다
+5. 개인적으로는 현실세계에서 발생하는 수많은 버그들은 도메인 모델링이 제대로 만들어지지 않았거나, 혹은 잘못 만들어져서 소통에 오류가 생겼거나, 유지보수가 되지 않음으로써 버그가 발생했다든지 결국엔 소통의 문제로 귀결될 수 있을것 같고, 도메인 모델링을 어떻게 잘 설계하고, 이를 통해서 잘 소통하고, 유지보수 해나가는지가 버그 없는 소프트웨어를 만드는데 중요한 부분 이라고 생각한다

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

@@ -0,0 +1,26 @@
+# 2장 유비쿼터스 언어
+
+# 논의 내용
+
+1. 책에서 말하는 유비쿼터스 언어를 제대로 설정하지 않아서, 소통의 오류가 발생한 경우가 있다면, 이에 대해서 얘기해보고, 어떻게 해결했는지, 현재는 업무상에서 어떻게 고려하고 있는지 공유해보면 좋을 것 같습니다
+2. 어떻게 여러 직군들 간에 소통 오류 없이 이해하고, 이를 코드에도 고스란히 반영하기 위한 모델을 어떻게 만들 것인지에 대해서, 개인적으로 고민이 있고, 여러가지 실험들도 해보고 있습니다. 책에선 UML이 나왔는데, 저는 UML도 활용하지만, 최근엔 도메인 스토리텔링 이라는 기법 또한 같이 활용하고 있습니다 제가 도메인 모델링에 이걸 활용하는 이유는 다이어그램이 그리기 쉽고, 해당 도메인이 한눈에 들어오게 정리 할 수 있기 때문 입니다. 아래 링크에 있는 자료를 보고, 도메인을 모델링하는 도구로써 어떻게 생각하셨는지 의견 나눠보면 좋을 것 같습니다
+    1. 관련 블로그 글
+        1. https://yozm.wishket.com/magazine/detail/2307/
+        2. https://brunch.co.kr/@graypool/277
+        3. https://brunch.co.kr/@graypool/278
+    2. 관련 도서
+        1. https://www.aladin.co.kr/m/mproduct.aspx?ItemId=335716939&srsltid=AfmBOoq_UDjr4grr47tRit0ZvzkSshgI42jFlJFVU77bob_6l2kxrg-z
+
+# 키워드
+
+1. 도메인 전문가
+2. 유비쿼터스 언어
+
+# 내 생각
+
+1. 개발자와 도메인 전문가 간에 서로 알고 있는 지식, 즉, 멘탈 모델이 다르기 때문에 결국에 원활한 소통을 위해서는 어떤 중간 지점이 필요한데, 그것이 바로 도메인 모델링으로 설명할 수 있을 것 같다 이때 중요한 것은 모두가 이해할 수 있는 보편 언어로 작성이 되어야 한다는 것이고 이를 책에서는 유비쿼터스 언어라고 칭한다 누구나 이해할 수 있는 보편언어는 도메인 모델을 같이 만들어가는 관계자들 간에 협의에 의해서 만들어져야하고, 이를 통해서 원활한 소통이 되기를 기대하게 된다
+2. 그러나, 현실세계 기준으로 봤을 때, 책에 나오는 모두가 소통에 원활한 아름다운 상황은 생각 보다 거의 없는 것 같다 개발자들은 그들의 개발용어들을, 도메인 전문가들은 그들만 아는 비즈니스 용어들을 같은 서로 협의되지 않은 용어를 사용하면서, 서로의 말을 이해하지 못하여서 소통에 어려운 경우에 빠지는 것을 많이 보았다. 허나 그나마 다행이라고 생각하는 점은 각 직군의 사람들이 의도적으로 어렵거나, 본인들만 아는 용어를 쓴다기 보다는, 무의식적으로 사용하는 경우가 더 많았다는 점이다 즉, 다른 직군과의 소통이 익숙치 않은 것으로 부터 발생한 문제이기 때문에, 책에서 말하는 이런 공통언어를 협의하여 정하고 이를 바탕으로 소통하는 연습을 의도적으로 함으로써, 개선 시킬 수 있지 않을까? 라는 생각이다
+3. 도메인 모델은 유비쿼터스 언어를 기반으로 만들어져야 한다. 이게 기본이 되어야 모델링을 하는 그 다음 스텝으로 갈 수가 있다.
+4. 모델과 코드 간에는 의존성이 존재하고, 모델은 상대적으로 더 추상화 된 것, 반면에 코드는 추상화된 모델을 구체화한 것으로 볼 수 있다. 따라서, 모델이 변경되면 코드가 반드시 그에 맞게 수정되어야하고, 반대로 코드가 수정되면, 그에 맞게 모델 또한 수정이 되어야 한다. 
+5. 코드와 모델간에 어떤 방향으로 동기화를 해야 하는게 좋을지에 대해서는 좀 더 논의가 필요한 부분인데, 개인적으로는 기본적으론 모델 기준으로 설계의 변경을 먼저 고려한 이후에 이를 코드에 반영하는 쪽이 더 나은 방향이 아닐까 생각이된다
+6. 책에 모델로써, UML을 사용하는 것에 대한 얘기가 나온다. 나도 UML을 소통의 수단으로 활용하는 것을 매우 찬성하는 바이다 하지만, 맹목적으로 너무 구체적인 것들까지 UML로 표현하려고 하는 것은 반대하는 입장이다. 왜냐하면, UML을 작성하고, 유지보수하는 것도 모두 비용이기 때문이다. 특히, 문서화의 중요성을 말하는 사람들이 문서를 어떻게 작성할 것인가에 대해선 줄기차게 주장을 하면서도, 문서의 유지보수에 대해선 고려하지 않는 경우를 많이 보았다. 변경사항이 있다면 문서 또한 수정을 해줘야 하는데, 회사 생활 하면서, 문서를 잘쓰는 사람은 정말 많이 봤지만 유지보수를 제대로 하는 사람은 (나를 포함해…) 한명도 못본 것 같다. 개인적인 생각에 문서 유지보수를 못하는 이유는 애초에 문서를 유지보수 할 것을 고려하지 않고, 무작정 구체적인 내용들까지 적기 때문이다. 예를 들어서, 코드의 비즈니스로직을 나타내는 sequence diagram을 그렸다고 했을 때, 실제 코드와 완전히 매핑된 sequence diagram을 그렸다면, 이는 코드와 완전 매핑이 되기 때문에, 아주 정확하게 잘 그린 UML이라고 볼 수 있고, 정보로써 매우 가치가 있다고 볼 수 있다 but, 이 코드가 수정된다면? 수정이 매우 자주 된다면? 이 정확한 정보로써의 가치를 유지하기위해서, UML 또한 변경을 해줘야하는데, 대부분이 이부분은 신경을 쓰지 않는 것 같다. 결국에는 sequence diagram은 코드 변경에 따라 유지보수가 되지 않게되고, 이게 쌓이게 되면, 나중엔 필요없는 문서가 되게 되는 것이다. 그래서 나의 경우엔 애초에 구체적인 코드를 나타내는 UML의 경우는 애초에 유지보수가 불가하다는 전제를 두고, 소통을 위해 꼭 필요한 일회성 UML을 그리는 용도로 사용하거나, 이 문서는 반드시 유지보수를 해야한다는 전제하에 구체적인 내용이 아닌 추상화 된 내용을 표현하도록 하는 방식을 사용하고 있다

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

@@ -0,0 +1,43 @@
+# 3장 모델 주도 설계
+
+# 논의 내용
+
+1. 책에서 절차지형적인 코드는 복잡한 도메인을 표현하기에 한계가 있다고 설명하고 있습니다. 실제 제가 경험해보거나 주변에서 들어본 사례를 보면, 각 회사들의 production에서 운영중인 비즈니스 로직 코드들을 보면, 도메인이 복잡한 것과 별개로, 거의 대부분 트랜잭션 스크립트로 작성 되어 있습니다. 객사오, 오브젝트 같은 책들을 좋다는 개발자들은 많이 봤지만, 정작 작성하는 코드들은 객체지향적이지 않은 코드들이 거의 대부분이였던 것 같습니다. 혹시 저말고 다른 분들도 비슷한 경험이신지 궁금하고, 이유가 무엇일지? 에 대해서도 의견을 부탁 드립니다 아래는 제가 생각해본 이유 입니다
+    - 이유
+        - 첫째, 각 회사들의 비즈니스로직이 트랜잭션 스크립트 만으로도 표현이될 만큼 충분히 복잡하지 않기 때문일까?
+        - 둘째, 아니면, 개발자들이 도메인 객체들을 활용한, 객체지향 코딩을 할만한 역량이 갖춰지지 않았기 때문일까?
+2. 집합(aggregate) 객체를 책에 나오는 불변식(invariant)과 root 개념을 활용하여서, 현업에서도 잘 설계해서 사용하고 계신지 궁금합니다 사례가 있다면 공유해주시면 좋을 것 같습니다
+3. 본인이 생각하는 서비스 객체의 역할은 무엇인지 얘기 보면 좋을 것 같습니다
+4. 서비스 객체의 오남용 사례에 대해서 본인이 겪은 일이 있는지 얘기해보면 좋을 것 같습니다
+5. 서비스 라는 이름이 과연 적절한 표현인가에 대한 본인의 의견이 있다면, 의견 부탁 드립니다
+
+
+# 키워드
+
+1. 계층형 아키텍쳐
+2. 엔티티
+3. 값객체
+4. 서비스
+5. 모듈
+6. 집합
+    1. 불변식
+    2. root
+7. 팩토리
+8. 리파지토리
+
+# 내 생각
+
+1. 책에서는 복잡한 프로그램의 유지보수성과 테스트 가능성을 높이기 위한 해결책으로, 레이어를 나누는 것을 제안하고 있다 이를 흔히 레이어드 아키텍쳐 라고 한다 나는 이 의견에 매우 동의 한다 하지만 얼만큼 어떻게 나눌 것인가는 논쟁거리가 될 수 있다고 생각한다. 각 개인마다 본인의 경험과 맥락에서 정해진 상대적 기준들이 있기 때문이다. 그래서 흔히들 얘기되는것은 레이어드 아키텍쳐, 헥사고날 아키텍쳐 등등인데, 개인적으로 책에서 말하는 내용을 정답이라고 생각해서는 안된다고 생각한다 그 이유는 책에서는 복잡한 도메인을 코드로 표현해야한다는 전제가 깔려 있기 때문이다. 반대로 생각해보면, 복잡하지 않다면, 위의 아키텍쳐들을 굳이 따를 필요가 없다고 생각한다. 또한 이 코드가 정말로 한번 개발된 이후에 다시 수정될 일이 없다면, 역시나 위의 아키텍쳐를 따를 필요가 없다고 생각한다. 우리가 무의식적으로 말하는 확장성을 고려한 설계와 코드, 아키텍쳐 같은 것들이 정말로 현재 내 업무 도메인에 적합한 것인지는 반드시 고민해봐야하는 문제이고, 무작정 클린아키텍쳐나 헥사고날 같은 것들을 도입하자고 말하지 않아야한다. 정말로 클린아키텍쳐와 헥사고날이 필요할 만큼 유지보수성과 테스트 가능성, 확장성을 고려할만하다고 판단될 때 활용하도록 해야한다고 생각한다
+2. 서비스 라는 용어가 업계에서 오남용되고 있는 용어 중에 하나라고 생각 한다. 이유는 각 사람들마다 이 용어를 받아들이고 사용하는 기준이 다 다르다고 느꼈기 때문이다. Service 가 정말로 무엇인지, 왜 Service 라는 접미어를 붙여서 클래스를 만들어야하는지, @Service 애노테이션을 붙이는 기준은 무엇인지? 등등 관련된 질문을 속시원하게 답변해주는 사람을 아직까지 만나 보지 못하였다. 가장 흔한 답변은 controller 가 의존하고 있는 비즈니스로직이 구현된 공간이라는 정도이고, 대략 그냥 비즈니스로직 작성하는 객체라고 많이들 부르는 것 같다. 여기서 말하는 비즈니스 로직 이라는 것도, 각 개발자 마다 생각하는 범위가 다르다보니, 이 내용을 해석하는 개발자의 생각도 제각각이고, 이로인해서, 수많은 정체모를 서비스 객체들이 만들어지게 되고, 여기에 @Service 애노테이션을 붙이는게 맞냐 아니냐, Service 객체끼리 의존성을 가지는게 맞는 것인가?, 도메인 서비스는 도메인의 서비스 이기 때문에, POJO 형태로 되어야한다, 아니다 상황에 따라서 리파지토리를 의존하는 경우도 있다 등등의 수많은 논란이 있다고 생각한다.(파이썬 진영에서는 자바 스프링과 별개로 또 다르게 해석하는 경우를 많이 보았는데, 이는 python business logic, service layer 등등의 검색어를 찾아봐도 쉽게 찾을 수 있다) 이런 오남용 사례가 쌓이면서, 결국에는 명시적으로 서비스가 무엇이다라고 정의 하지 못하고, 대략 감으로 이건 서비스이다 아니다 정도로만 판단하고 코드를 작성하는게 현실이지 않나? 라는 생각이다
+3. 그래서 개인적으로는 서비스의 역할을 다음과 같이 구분을 한다.
+    1. 트랜잭션 스크립트를 작성할 때,
+        1. 비즈니스 로직을 어떤 작업 절차  단위로 적절히 나눠서, 작성하는 곳
+            1. 이때의 작업 절차 단위는 private method로 작성 할 수도 있고,(로직이 간단하다면,) 로직이 간단하지 않다면, 별도의 이를 구현하는 하위 객체를 생성해서도 작성할 수 있을 것으로 보인다
+    2. 도메인 객체를 활용한 객체지향적인 코드를 작성할 때,
+        1. 도메인 객체, 리파지토리 객체, 값 객체, 등등 여러 객체들을 모아서 조정(coordination)하는 역할 이라고 하고, 이를 애플리케이션  서비스라 부른다. java spring 기준으로 봤을 때는 controller가 의존하는 객체이어야 하고, @Service 애노테이션이 붙어야한다
+        2. 어떤 로직을 도메인 객체의 어떤 부분에도 넣기 애매할 때, 도메인 객체의 서비스 라는 의미로 도메인 서비스 객체라 부른다 위의 애플리케이션 서비스와 다르게, 계층 구조상으로 애플리케이션 서비스가 도메인 서비스를 의존하는 형태이기 때문에, 이때 @Service 애노테이션은 붙이지 않아야 한다 의존성 주입이 필요하다면, 대신 다른 애노테이션을 붙여야한다(예를 들면, @Component)
+            1. `자바/스프링 개발자를 위한 실용주의 프로그래밍` 책을 보면, 도메인 서비스의 경우는 다시 도메인 객체로 치환할 수 있음을 말하는데(책 기준 도메인 서비스를 PriceManager 라는 객체로 예를 든다), 이부분은 설계의 문제이다. 즉, 도메인 모델링을 좀 더 상세히 고민해봄으로써, 도메인 서비스를 별도의 도메인 객체로 다시 설계 할 수 있다
+4. 모듈의 경우, 요즘 국내의 java spring 트렌드를 봤을 때, 멀티모듈 등으로 많이 언급되는 것으로 알고 있고, 패키지 이상의 무언가를 의미하는 것으로 알고 있는데, 책에서는 패키지 정도 수준에서 설명하는 것 처럼 느껴졌다
+5. 집합에 대해서 책에 길게 설명이 나오는데, 간단히 말하면, 엔티티의 수정이 필요할 때, 수정을 위한 인터페이스를 제공하는 어떤 객체들의 집합이라고 말할 수 있고, 이 객체들의 집합은 수정 시에 한 트랜잭션으로 묶여서 동작되어야만 한다. 책에 집합 root 라는 것이 나오는데, 이 root는 직접적으로 인터페이스를 제공하는 객체이며, 이 객체를 통해서만 수정이 가능하도록 하는게 집합을 사용하는, 집합을 설계하는 목적이다. 책에 불변식이라는 말도 나오는데, 이 root에서 불변식을 가지고 있고, 수정 전에 root 단에서 불변식을 체크하도록 한다. 정리하면, 어떤 엔티티의 수정이 필요할 때, 불변식을 가지고 있는 root 엔티티가 제공하는 인터페이스를 호출을 하여서, 집합으로 묶인 객체들을 한 트랜잭션 내에서, 수정할 수 있게 하는 어떤 것이라고 말할 수 있다
+    1. 책의 예제 기준으로 설명하자면, ContactInfo 정보 중 하나를 수정하고 싶은 경우에 흔히 ContactInfo에 직접 접근하거나, ContractInfo의 별도 인터페이스를 통해서 값을 수정할 수 있다고 생각을 하는데, 집합은 의도적으로 ContactInfo의 값을 수정하기 위해, ContractInfo를 수정 이전에 체크가 필요한 불변식을 가지고 있는, root 엔티티의 인터페이스로만 수정할 수 있도록 한다. 즉, 수정할 수 있는 경로에 제한을 두는 것이다
+6. 팩토리와 리파지토리의 경우는 책에서 나온 것과 같이 리파지토리 쪽은 영속성과 관련된 객체, 팩토리는 메모리 상에서 만들어지는 객체의 생성과 관련된 것으로 이해하는게 좋다고 생각을 하였다