도메인 주도 설계란 무엇인가? 1주차 - 권태형 #503
Conversation
TaeHyoungKwon
requested review from
wooyaggo86,
jongfeel,
jintaeyeong,
hemil0102,
ymkim97,
aquamagic9,
fkdl0048,
tttghost and
dhlee3994
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @TaeHyoungKwon, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
I've summarized the changes in this pull request, which includes three new markdown files (1.md, 2.md, and 3.md) under the directory 2025/Domain-Driven Design Quickly/taehyoung/. These files contain notes and thoughts on the book 'Domain-Driven Design Quickly', specifically covering chapters 1, 2, and 3. Each file includes sections for discussion points, keywords, and personal reflections on the chapter's content.
Highlights
- Chapter Summaries: The pull request adds summaries and discussion points for the first three chapters of 'Domain-Driven Design Quickly'.
- Discussion Points: Each chapter summary includes discussion points related to applying the concepts in real-world scenarios and experiences.
- Personal Reflections: The author shares their personal thoughts and interpretations of the concepts presented in each chapter.
Changelog
Click here to see the changelog
- 2025/Domain-Driven Design Quickly/taehyoung/1.md
- Created a new markdown file summarizing Chapter 1 of 'Domain-Driven Design Quickly'.
- Included discussion points about the practical application of domain models and their maintenance.
- Listed keywords related to domain-driven design, such as 'domain,' 'modeling,' and 'abstraction'.
- Added personal thoughts on the importance of focusing on real-world problems and the role of domain modeling in communication.
- 2025/Domain-Driven Design Quickly/taehyoung/2.md
- Created a new markdown file summarizing Chapter 2 of 'Domain-Driven Design Quickly'.
- Included discussion points about ubiquitous language and its impact on communication.
- Referenced external resources on domain storytelling as a modeling technique.
- Added personal thoughts on the challenges of establishing a common language between developers and domain experts.
- 2025/Domain-Driven Design Quickly/taehyoung/3.md
- Created a new markdown file summarizing Chapter 3 of 'Domain-Driven Design Quickly'.
- Included discussion points about the prevalence of transaction scripts and the role of service objects.
- Listed keywords related to model-driven design, such as 'entity,' 'value object,' and 'aggregate'.
- Added personal thoughts on layered architecture, service object usage and the meaning of 'service', and the concepts of aggregates, factories and repositories.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Trivia time!
What is UML, and what are some of its diagram types?
Click here for the answer
UML stands for Unified Modeling Language. It is a standardized general-purpose modeling language in the field of software engineering. Some of its diagram types include class diagrams, sequence diagrams, use case diagrams, and activity diagrams.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
The pull request adds markdown files discussing Domain-Driven Design concepts. The content is well-structured and provides insightful thoughts and discussion points related to the book 'Domain-Driven Design Quickly'. Overall, the content is good, but I have a few suggestions to improve clarity and consistency.
Merge Readiness
The pull request is in good shape to be merged. The content is informative and well-organized. Addressing the minor suggestions would further enhance the quality of the content. I am unable to directly approve the pull request, and users should have others review and approve this code before merging.
|
우측에 있는 |
| 3. 본인이 생각하는 서비스 객체의 역할은 무엇인지 얘기 보면 좋을 것 같습니다 | ||
| 4. 서비스 객체의 오남용 사례에 대해서 본인이 겪은 일이 있는지 얘기해보면 좋을 것 같습니다 | ||
| 5. 서비스 라는 이름이 과연 적절한 표현인가에 대한 본인의 의견이 있다면, 의견 부탁 드립니다 |
There was a problem hiding this comment.
위 내용과 관련된 이규원님이 페북에 적은 글이 있으신데요 이 글도 한번 같이 보시면 좋을 거 같습니다
글 링크가 제공이 안되서 페북에서 직접 검색해서 보셔야할 것 같습니다
There was a problem hiding this comment.
자바/스프링 개발자를 위한 실용주의 프로그래밍 책에서 서비스에 대해서 말하는 부분이 있어서 책 페이지 일부 첨부합니다
|
|
||
| # 논의 내용 | ||
|
|
||
| 1. 개인적으로는 단순히 UML 혹은 다이어그램으로 표현되는 단순한 형태의 도식화된 그림 만으로는, 도메인 모델로써 확실히 부족한 면이 있다고 생각하는 편 입니다. 디테일한 세부사항까지는 커버하기 힘들기 때문 입니다. 그래서 최근에 제가 생각하고 있는 것은 대략적인 도메인의 큰 그림을 보여줄 수 있는 도메인을 표현한 다이어그램, UML 등과 함께 세부사항이 적힌 정책서 두가지를, 유지보수가 반드시 필요한 모델로 지정하고, 적용해보고 있는 중 입니다. 책을 읽으면서, 혹은 업무를 하면서, 현실에 적용이 가능하다는 전제하에, 본인이 생각한 모델의 구체적인 사례가 있다면 얘기해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
도메인 용어 위키 같은 곳에 정책을 작성하는 것을 생각했습니다. 회사에서 인수인계 용도로 작성해봤는데, 인수인계 비용이 많이 줄었다고 느꼈습니다.
|
|
||
| 1. 개인적으로는 단순히 UML 혹은 다이어그램으로 표현되는 단순한 형태의 도식화된 그림 만으로는, 도메인 모델로써 확실히 부족한 면이 있다고 생각하는 편 입니다. 디테일한 세부사항까지는 커버하기 힘들기 때문 입니다. 그래서 최근에 제가 생각하고 있는 것은 대략적인 도메인의 큰 그림을 보여줄 수 있는 도메인을 표현한 다이어그램, UML 등과 함께 세부사항이 적힌 정책서 두가지를, 유지보수가 반드시 필요한 모델로 지정하고, 적용해보고 있는 중 입니다. 책을 읽으면서, 혹은 업무를 하면서, 현실에 적용이 가능하다는 전제하에, 본인이 생각한 모델의 구체적인 사례가 있다면 얘기해보면 좋을 것 같습니다 | ||
|
|
||
| 2. 업무할 때, 사용하고 있는 구체적인 도메인 모델이 있다는 가정하에(아마도 대개의 경우는 도메인을 정리하고 표현하기 위한 사내 위키문서, 기획서 등등 있지 않을까 생각됩니다), 그 도메인 모델의 유지보수는 실제로 어떻게 하고 있는지 얘기해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
업무할때는 아니지만 최근 부트캠프를 수료하면서 비슷한 상황을 경험했습니다.
이미 코드가 나간 뒤에 문서를 수정했었던 기억이 있습니다.
코드와는 별개의 문서이다 보니, 개발자가 항상 신경쓰지 않으면 유지보수가 잘 되지 않을 것 같습니다.
다른 분들은 어떻게 하는지 궁금하네요.
|
|
||
| # 논의 내용 | ||
|
|
||
| 1. 개인적으로는 단순히 UML 혹은 다이어그램으로 표현되는 단순한 형태의 도식화된 그림 만으로는, 도메인 모델로써 확실히 부족한 면이 있다고 생각하는 편 입니다. 디테일한 세부사항까지는 커버하기 힘들기 때문 입니다. 그래서 최근에 제가 생각하고 있는 것은 대략적인 도메인의 큰 그림을 보여줄 수 있는 도메인을 표현한 다이어그램, UML 등과 함께 세부사항이 적힌 정책서 두가지를 유지보수를 반드시 해야하는 모델로써 지정하고, 적용해보고 있는 중 입니다. 책을 읽으면서, 혹은 업무를 하면서, 현실에 적용이 가능하다는 전제하에, 본인이 생각한 모델의 구체적인 사례가 있다면 얘기해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
현재 회사에서는 피그마를 사용하여 디자이너&기획자&개발자 간에 도메인모델? 로 사용하고 있습니다.
이 회사에 와서 처음 피그마를 써보는데요. 실시간으로 같은 장면을 보고 이야기하는 과정이 좋았습니다.
이 과정에서 도메인 모델에 대해 추상적 그림을 그릴 수 있더라구요.
| 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 |
There was a problem hiding this comment.
저는 도메인 스토리텔링 다이어그램의 문법을 100% 지키진 않았지만, 대략 요런식으로 활용 해보고 있습니다
1,2 장 내용을 요약 했습니다
|
|
||
| # 논의 내용 | ||
|
|
||
| 1. 개인적으로는 단순히 UML 혹은 다이어그램으로 표현되는 단순한 형태의 도식화된 그림 만으로는, 도메인 모델로써 확실히 부족한 면이 있다고 생각하는 편 입니다. 디테일한 세부사항까지는 커버하기 힘들기 때문 입니다. 그래서 최근에 제가 생각하고 있는 것은 대략적인 도메인의 큰 그림을 보여줄 수 있는 도메인을 표현한 다이어그램, UML 등과 함께 세부사항이 적힌 정책서 두가지를, 유지보수가 반드시 필요한 모델로 지정하고, 적용해보고 있는 중 입니다. 책을 읽으면서, 혹은 업무를 하면서, 현실에 적용이 가능하다는 전제하에, 본인이 생각한 모델의 구체적인 사례가 있다면 얘기해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
제가 많이 경험했던 방식은 전체 시스템 구성도 쯤으로 부르는 그림과 약간의 설명이 있는 1~2페이지의 문서였습니다.
복잡한 시스템의 경우 디테일한 부분 까지 한 그림에 담을 수 없고,
그렇다고 디테일한 그림을 수십장 만들어 내는 건 책에서도 나와 있듯이 UML의 클래스 다이어그램 수백개를 한번에 그리는 것과 다를 바 없다라고 했으니까요.
그래서 추상화된 핵심 개념을 잘 표현하는 단어를 선정해서 한 덩어리의 작은 시스템 혹은 모듈 정도로 표현하고 그 사이의 연관 관계를 표현하는 것 정도가 제가 했던 방법이었습니다.
유스케이스 다이어그램 보다는 조금 더 디테일하고, UML 보다는 간소화한 방식이었던 것 같습니다.
사례로는 빌드 자동화 시스템을 젠킨스로 구축했을 때가 있었고
파일 전송의 핵심 기능과 이를 활용한 어플리케이션 레벨에서의 로직 연동 방식도 그런 모델링을 했었던 적이 있습니다.
|
|
||
| 1. 개인적으로는 단순히 UML 혹은 다이어그램으로 표현되는 단순한 형태의 도식화된 그림 만으로는, 도메인 모델로써 확실히 부족한 면이 있다고 생각하는 편 입니다. 디테일한 세부사항까지는 커버하기 힘들기 때문 입니다. 그래서 최근에 제가 생각하고 있는 것은 대략적인 도메인의 큰 그림을 보여줄 수 있는 도메인을 표현한 다이어그램, UML 등과 함께 세부사항이 적힌 정책서 두가지를, 유지보수가 반드시 필요한 모델로 지정하고, 적용해보고 있는 중 입니다. 책을 읽으면서, 혹은 업무를 하면서, 현실에 적용이 가능하다는 전제하에, 본인이 생각한 모델의 구체적인 사례가 있다면 얘기해보면 좋을 것 같습니다 | ||
|
|
||
| 2. 업무할 때, 사용하고 있는 구체적인 도메인 모델이 있다는 가정하에(아마도 대개의 경우는 도메인을 정리하고 표현하기 위한 사내 위키문서, 기획서 등등 있지 않을까 생각됩니다), 그 도메인 모델의 유지보수는 실제로 어떻게 하고 있는지 얘기해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
초기 문서를 만들고 변경 사항이 있으면 수정하자 쪽을 선호하는데
그것도 리뷰하고 문서 수정하고 히스토리 남기고 이걸 인지를 잘 못해서
최근에 Github Issue로 Document label 붙여서 유지보수 하는 쪽으로 해보고 있습니다.
사실, 저도 관리가 잘 되서 성공한 사례가 없긴 합니다.
코드는 잘 되는데 문서가 잘 안된다는게 미스터리이긴 해요.
|
|
||
| # 논의 내용 | ||
|
|
||
| 1. 책에서 말하는 유비쿼터스 언어를 제대로 설정하지 않아서, 소통의 오류가 발생한 경우가 있다면, 이에 대해서 얘기해보고, 어떻게 해결했는지, 현재는 업무상에서 어떻게 고려하고 있는지 공유해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
제 경험상 회의하거나 대화하면서 그런 부분을 발견하고 설계서나 기획서의 단어를 수정하는 쪽이 제일 많았습니다.
그 다음엔 서로 다른 얘기를 하고 있으면 누군가 'A' 얘기 맞죠? 라면서 환기를 시켜주는 것 정도죠.
그게 문서로 만들어져서 '이제 우리 프로젝트의 유비쿼터스 언어는 이렇게 정했습니다' 라고 한 적은 없긴 합니다.
그런데 최근 프로젝트 끝나고 나서 회고하는 시간을 통해 서로 이해한 모델 언어가 달라 클래스 이름이 달랐던 사례를 되돌아 보고
사전에 미리 용어 정의와 통일 하자는 의견을 냈고 합의를 봤습니다.
그게 유비쿼터스 언어라는 걸 알려주기도 했고요.
| # 논의 내용 | ||
|
|
||
| 1. 책에서 말하는 유비쿼터스 언어를 제대로 설정하지 않아서, 소통의 오류가 발생한 경우가 있다면, 이에 대해서 얘기해보고, 어떻게 해결했는지, 현재는 업무상에서 어떻게 고려하고 있는지 공유해보면 좋을 것 같습니다 | ||
| 2. 어떻게 여러 직군들 간에 소통 오류 없이 이해하고, 이를 코드에도 고스란히 반영하기 위한 모델을 어떻게 만들 것인지에 대해서, 개인적으로 고민이 있고, 여러가지 실험들도 해보고 있습니다. 책에선 UML이 나왔는데, 저는 UML도 활용하지만, 최근엔 도메인 스토리텔링 이라는 기법 또한 같이 활용하고 있습니다 제가 도메인 모델링에 이걸 활용하는 이유는 다이어그램이 그리기 쉽고, 해당 도메인이 한눈에 들어오게 정리 할 수 있기 때문 입니다. 아래 링크에 있는 자료를 보고, 도메인을 모델링하는 도구로써 어떻게 생각하셨는지 의견 나눠보면 좋을 것 같습니다 |
There was a problem hiding this comment.
안영회님 글은 읽긴 했었지만 크게 적용해 봐야겠다 까지는 못했었습니다.
해당 주제로 번역서가 있다는 걸 알아서 다음에 제가 개인적으로 읽을 책 목록에도 넣어 뒀습니다.
좋은 방법으로 참고하기에 좋은 것 같습니다.
막연하게 느껴질 떄 보면 좋을 것 같기도 하네요.
| 1. 개발자와 도메인 전문가 간에 서로 알고 있는 지식, 즉, 멘탈 모델이 다르기 때문에 결국에 원활한 소통을 위해서는 어떤 중간 지점이 필요한데, 그것이 바로 도메인 모델링으로 설명할 수 있을 것 같다 이때 중요한 것은 모두가 이해할 수 있는 보편 언어로 작성이 되어야 한다는 것이고 이를 책에서는 유비쿼터스 언어라고 칭한다 누구나 이해할 수 있는 보편언어는 도메인 모델을 같이 만들어가는 관계자들 간에 협의에 의해서 만들어져야하고, 이를 통해서 원활한 소통이 되기를 기대하게 된다 | ||
| 2. 그러나, 현실세계 기준으로 봤을 때, 책에 나오는 모두가 소통에 원활한 아름다운 상황은 생각 보다 거의 없는 것 같다 개발자들은 그들의 개발용어들을, 도메인 전문가들은 그들만 아는 비즈니스 용어들을 같은 서로 협의되지 않은 용어를 사용하면서, 서로의 말을 이해하지 못하여서 소통에 어려운 경우에 빠지는 것을 많이 보았다. 허나 그나마 다행이라고 생각하는 점은 각 직군의 사람들이 의도적으로 어렵거나, 본인들만 아는 용어를 쓴다기 보다는, 무의식적으로 사용하는 경우가 더 많았다는 점이다 즉, 다른 직군과의 소통이 익숙치 않은 것으로 부터 발생한 문제이기 때문에, 책에서 말하는 이런 공통언어를 협의하여 정하고 이를 바탕으로 소통하는 연습을 의도적으로 함으로써, 개선 시킬 수 있지 않을까? 라는 생각이다 | ||
| 3. 도메인 모델은 유비쿼터스 언어를 기반으로 만들어져야 한다. 이게 기본이 되어야 모델링을 하는 그 다음 스텝으로 갈 수가 있다. | ||
| 4. 모델과 코드 간에는 의존성이 존재하고, 모델은 상대적으로 더 추상화 된 것, 반면에 코드는 추상화된 모델을 구체화한 것으로 볼 수 있다. 따라서, 모델이 변경되면 코드가 반드시 그에 맞게 수정되어야하고, 반대로 코드가 수정되면, 그에 맞게 모델 또한 수정이 되어야 한다. |
There was a problem hiding this comment.
하지만 실천하고 습관으로 만드는 건 어렵긴 한 거 같아요.
저는 정말 모델링(설계)과 코드가 일치하도록 지속적으로 업데이트 하고 수정하는 걸 실천하는 쪽입니다.
| 1. 책에서 절차지형적인 코드는 복잡한 도메인을 표현하기에 한계가 있다고 설명하고 있습니다. 실제 제가 경험해보거나 주변에서 들어본 사례를 보면, 각 회사들의 production에서 운영중인 비즈니스 로직 코드들을 보면, 도메인이 복잡한 것과 별개로, 거의 대부분 트랜잭션 스크립트로 작성 되어 있습니다. 객사오, 오브젝트 같은 책들을 좋다는 개발자들은 많이 봤지만, 정작 작성하는 코드들은 객체지향적이지 않은 코드들이 거의 대부분이였던 것 같습니다. 혹시 저말고 다른 분들도 비슷한 경험이신지 궁금하고, 이유가 무엇일지? 에 대해서도 의견을 부탁 드립니다 아래는 제가 생각해본 이유 입니다 | ||
| - 이유 | ||
| - 첫째, 각 회사들의 비즈니스로직이 트랜잭션 스크립트 만으로도 표현이될 만큼 충분히 복잡하지 않기 때문일까? | ||
| - 둘째, 아니면, 개발자들이 도메인 객체들을 활용한, 객체지향 코딩을 할만한 역량이 갖춰지지 않았기 때문일까? | ||
| 2. 집합(aggregate) 객체를 책에 나오는 불변식(invariant)과 root 개념을 활용하여서, 현업에서도 잘 설계해서 사용하고 계신지 궁금합니다 사례가 있다면 공유해주시면 좋을 것 같습니다 | ||
| 3. 본인이 생각하는 서비스 객체의 역할은 무엇인지 얘기 보면 좋을 것 같습니다 | ||
| 4. 서비스 객체의 오남용 사례에 대해서 본인이 겪은 일이 있는지 얘기해보면 좋을 것 같습니다 | ||
| 5. 서비스 라는 이름이 과연 적절한 표현인가에 대한 본인의 의견이 있다면, 의견 부탁 드립니다 |
There was a problem hiding this comment.
이거 제가 좋아하는 주제이기도 하고, 멘토링 할 때도 엄청 진지하게 얘기하는 거라
시간이 허락한다면 이 얘기를 좀 많이 해보고 싶긴 하네요.
첫째, 비즈니스 로직이 꼭 객체지향의 방식을 따르지 않더라도 되기 때문이다가 제 생각입니다.
둘째, 개발자들이 객체지향 코딩의 역량도 없기 때문도 맞는 것 같습니다. 처음에 배우는 상속 구조, 메서드 오버라이딩 정도가 객체지향 코드를 구현하는 것의 전부라고 생각하기 때문에, 진짜 객체지향 책에서 얘기하는 역할, 책임, 협력과 같은 뜬구름 잡는 얘기를 직접 코드로 어떻게 구현해야 하는지 모른다가 더 정확한 표현인 것 같습니다.
집합은 잘 사용하는 것 같진 않고 캡슐화 정도를 적용해서 꼭 필요한 인터페이스만 root라는 객체에 노출시키는 것 정도로 응용은 하는 것 같아요.
-
어떤 의존성이 호출하는 객체와 함께 다른 객체와 연결되어 있지 않아서 객체들의 상태를 변화시키지 않고 순수하게 숨겨져 있는 복잡성에 대해 간단한 요청으로 예상 결과를 응답할 수 있는 객체들의 집합이라고 봅니다.
-
딱히 생각나는 건 없긴 합니다.
-
첨부해 주신 내용을 보고 든 생각인데 클래스 이름까지 서비스여야 할 필요 까진 없다에 동의합니다. 저도 spring boot에서 service라는 어노테이션과 클래스 이름 그리고 그걸 구현한걸 또 Impl이라는 접미사를 붙인 것 까지 보고 이 동네 하우스룰 정도로만 생각했었는데 아주 반감이 있거나 잘못됐다 라는 생각까진 안한 것 같습니다.
책 내용과 관련해서 하고 싶은 말들이 많다보니, 책은 진작에 읽었는데, 정리가 좀 늦었네요 책은 재미있게 읽었습니다
Close #494