도메인 주도 설계란 무엇인가? 2주차 - 권태형 #518
Conversation
TaeHyoungKwon
requested review from
aquamagic9,
dhlee3994,
fkdl0048,
hemil0102,
jintaeyeong,
jongfeel,
tttghost,
wooyaggo86 and
ymkim97
![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
This pull request by TaeHyoungKwon adds a markdown file (5.md) to the 'Domain-Driven Design Quickly' section, specifically focusing on Chapter 5, which discusses preserving model integrity. The content includes notes and thoughts on the chapter, particularly around the concept of "Divided Contexts" within Domain-Driven Design (DDD). The author shares their understanding of how to apply these concepts in real-world scenarios, such as team organization and microservices architecture.
Highlights
- Chapter Summary: The pull request provides a summary of Chapter 5 of 'Domain-Driven Design Quickly', focusing on maintaining model integrity in large systems.
- Divided Contexts: It emphasizes the importance of 'Divided Contexts' and how they relate to team structures and microservices architecture.
- Strategic vs. Tactical DDD: The author highlights the significance of strategic DDD (defining contexts and relationships) over tactical DDD (entities, repositories).
Changelog
- 2025/Domain-Driven Design Quickly/taehyoung/5.md
- Added a new markdown file summarizing Chapter 5 of 'Domain-Driven Design Quickly'.
- Included discussion points related to defining divided contexts.
- Listed keywords related to the chapter's content, such as 'Context', 'Shared Kernel', and 'Anti-corruption Layer'.
- Shared personal thoughts on applying DDD principles in organizational structures and microservices.
- Emphasized the importance of strategic design in DDD.
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.
A context defined,
Boundaries carefully aligned,
A model's domain.
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 provides a summary and personal thoughts on Chapter 5 of the book 'Domain-Driven Design Quickly'. The content is well-structured and reflects a good understanding of the chapter's key concepts. However, there are a few areas where minor improvements can be made to enhance clarity and readability.
Merge Readiness
The pull request is in good shape and provides valuable insights into the chapter's content. I am unable to directly approve the pull request, and users should have others review and approve this code before merging. There are no critical or high severity issues, so it can be merged after addressing the medium severity issues.
| 1. 본인 혹은 회사에서 이런 분할된 컨텍스트를 정의해본 경험이 있다면 같이 얘기해보면 좋을 것 같습니다 | ||
| 1. 책에 분할된 컨텍스트를 나눠야한다는 말은 나옵니다. 하지만, 어떤 방식으로, 어떻게 나눠야한다는 말은 나오지 않습니다. 개인적으로 어떻게 나눠야한다는 내용이 나오지 않는 이유는 나누는 방법에 정답이 존재하지 않기 때문이 아닌가라는 생각입니다. | ||
| 2. 즉, 각 개인과 조직 마다 상황에 따라서 적절히 나누면 되는 것이라는 뜻 입니다. 실제로 저희 회사에서도 마이크로서비스를 정의할 때, 어떤 구체적인 방법을 사용하지 않습니다. 어떻게 나누는게 좋을지에 대해서 구성원들 간의 토론을 통해서, 컨텍스트 경계의 범위가 적절한지를 결정하고 있습니다 |
There was a problem hiding this comment.
Consider rephrasing this for better readability. You could say something like: "It would be beneficial to discuss experiences with defining divided contexts, either personally or within a company setting. The book mentions the need for dividing contexts but doesn't specify how to do so. This lack of specific guidance suggests that there's no one-size-fits-all solution, and the approach should be tailored to individual and organizational circumstances."
| # 내 생각 | ||
|
|
||
| 1. 5장에 오기 전까지는 모델의 크기가 매우 크다는 전제를 하지 않은 상태라고 봐야할 것이다. 5장에서는 이 모델의 크기가 매우 크다는 전제하에서, 어떻게 모델의 무결성을 관리할 것인지에 대한 이야기를 전개해나간다 | ||
| 2. 여기서 중요한 것은 매우 큰 모델을 어떻게 나눌 것인가 라는 것이다. 이를 설명하기 위해서, 분할된 컨텍스트 라는 개념이 나오게 된다 분할된 컨텍스트는 도메인 모델이 적용되는 개념적인 경계로 말할 수 있는데, 어떤 기준을 가지고, 개념적으로 도메인을 분리해서 정의한 것으로 볼 수 있다. 분할된 컨텍스트를 좀 더 큰 범위에서 보면, 회사에서 도메인 별로 팀을 나눌 때, 모놀리식 서비스에서 마이크로서비스를 분리 할 때, 모두 분할된 컨텍스트의 맥락하에서 이해 해볼 수 있다 |
There was a problem hiding this comment.
Consider adding a brief explanation of what a '분할된 컨텍스트' (divided context) is in English for non-Korean speakers. This would improve the document's accessibility.
|
|
||
| 1. 5장에 오기 전까지는 모델의 크기가 매우 크다는 전제를 하지 않은 상태라고 봐야할 것이다. 5장에서는 이 모델의 크기가 매우 크다는 전제하에서, 어떻게 모델의 무결성을 관리할 것인지에 대한 이야기를 전개해나간다 | ||
| 2. 여기서 중요한 것은 매우 큰 모델을 어떻게 나눌 것인가 라는 것이다. 이를 설명하기 위해서, 분할된 컨텍스트 라는 개념이 나오게 된다 분할된 컨텍스트는 도메인 모델이 적용되는 개념적인 경계로 말할 수 있는데, 어떤 기준을 가지고, 개념적으로 도메인을 분리해서 정의한 것으로 볼 수 있다. 분할된 컨텍스트를 좀 더 큰 범위에서 보면, 회사에서 도메인 별로 팀을 나눌 때, 모놀리식 서비스에서 마이크로서비스를 분리 할 때, 모두 분할된 컨텍스트의 맥락하에서 이해 해볼 수 있다 | ||
| 3. 그 다음으로 나오는 내용들은 분할된 컨텍스트 간의 관계를 어떻게 설정할 것인가에 대한 것이다 이부분은 추상적인 개념으로 이해하기 보다도, 위에서 말한 것 처럼 실제 회사에서 팀을 어떤 기준으로 나누고, 팀 간의 관계를 어떻게 정의하는지, 마이크로서비스를 분리하고, 각 마이크로서비스 간에 어떤 관계를 정의하는지와 같은 구체적인 사례들을 기준으로 보면 훨씬 더 이해하기가 쉽다 |
There was a problem hiding this comment.
Consider rephrasing for clarity. For example: "The following topics discuss how to establish relationships between divided contexts. Instead of viewing this as an abstract concept, consider concrete examples such as how teams are organized and how they interact within a company, or how microservices are separated and related to each other."
| 1. 5장에 오기 전까지는 모델의 크기가 매우 크다는 전제를 하지 않은 상태라고 봐야할 것이다. 5장에서는 이 모델의 크기가 매우 크다는 전제하에서, 어떻게 모델의 무결성을 관리할 것인지에 대한 이야기를 전개해나간다 | ||
| 2. 여기서 중요한 것은 매우 큰 모델을 어떻게 나눌 것인가 라는 것이다. 이를 설명하기 위해서, 분할된 컨텍스트 라는 개념이 나오게 된다 분할된 컨텍스트는 도메인 모델이 적용되는 개념적인 경계로 말할 수 있는데, 어떤 기준을 가지고, 개념적으로 도메인을 분리해서 정의한 것으로 볼 수 있다. 분할된 컨텍스트를 좀 더 큰 범위에서 보면, 회사에서 도메인 별로 팀을 나눌 때, 모놀리식 서비스에서 마이크로서비스를 분리 할 때, 모두 분할된 컨텍스트의 맥락하에서 이해 해볼 수 있다 | ||
| 3. 그 다음으로 나오는 내용들은 분할된 컨텍스트 간의 관계를 어떻게 설정할 것인가에 대한 것이다 이부분은 추상적인 개념으로 이해하기 보다도, 위에서 말한 것 처럼 실제 회사에서 팀을 어떤 기준으로 나누고, 팀 간의 관계를 어떻게 정의하는지, 마이크로서비스를 분리하고, 각 마이크로서비스 간에 어떤 관계를 정의하는지와 같은 구체적인 사례들을 기준으로 보면 훨씬 더 이해하기가 쉽다 | ||
| 4. 위 관점에서 보면, 분할된 컨텍스트의 관계에 관련된 키워드들은 전혀 어렵지 않고, 지극히 상식적인 이야기 임을 알 수 있다. 그리고 흔히 많은 사람들이 말하는 DDD가 단순히 엔티티, 리파지토리 등등의 전술적 설계에서의 빌딩블록들을 다루는 것 이상으로 코드 자체가 아닌, 실생활에 더 밀접하게 연관된 것임을 알 수 있다. 개인적으로는 회사에서 실용적으로 DDD를 활용하고자 한다면, 분할된 컨텍스트를 어떻게 나눌 것이고, 그중에서도 핵심 도메인과, 서브 도메인은 어떻게 나눌 것인지, 분할된 컨텍스트 간의 관계를 어떻게 정의하고 운영할것인가, 분할된 컨텍스트 하의 모델들의 유비쿼터스 언어를 관리하고, 모델의 무결성이 없도록 할지에 대해서 더 집중하는게 좋다고 생각하고, 이게 DDD의 더 핵심적인 부분이라고 생각한다. 이를 전략적 설계라고 하고, 전술적 설계는 전략적 설계가 전제된 상태에서 고려되어야한다고 생각한다 |
There was a problem hiding this comment.
Consider rephrasing for better flow: "From this perspective, the keywords related to divided context relationships are straightforward and intuitive. Many people associate DDD with tactical design elements like entities and repositories, but it extends beyond code to real-world applications. To effectively utilize DDD in a company, focus on how to divide contexts, differentiate between core and sub-domains, define and manage relationships between contexts, maintain a ubiquitous language, and ensure model integrity. This strategic design is more critical than tactical design and should be considered first."
| 2. 여기서 중요한 것은 매우 큰 모델을 어떻게 나눌 것인가 라는 것이다. 이를 설명하기 위해서, 분할된 컨텍스트 라는 개념이 나오게 된다 분할된 컨텍스트는 도메인 모델이 적용되는 개념적인 경계로 말할 수 있는데, 어떤 기준을 가지고, 개념적으로 도메인을 분리해서 정의한 것으로 볼 수 있다. 분할된 컨텍스트를 좀 더 큰 범위에서 보면, 회사에서 도메인 별로 팀을 나눌 때, 모놀리식 서비스에서 마이크로서비스를 분리 할 때, 모두 분할된 컨텍스트의 맥락하에서 이해 해볼 수 있다 | ||
| 3. 그 다음으로 나오는 내용들은 분할된 컨텍스트 간의 관계를 어떻게 설정할 것인가에 대한 것이다 이부분은 추상적인 개념으로 이해하기 보다도, 위에서 말한 것 처럼 실제 회사에서 팀을 어떤 기준으로 나누고, 팀 간의 관계를 어떻게 정의하는지, 마이크로서비스를 분리하고, 각 마이크로서비스 간에 어떤 관계를 정의하는지와 같은 구체적인 사례들을 기준으로 보면 훨씬 더 이해하기가 쉽다 | ||
| 4. 위 관점에서 보면, 분할된 컨텍스트의 관계에 관련된 키워드들은 전혀 어렵지 않고, 지극히 상식적인 이야기 임을 알 수 있다. 그리고 흔히 많은 사람들이 말하는 DDD가 단순히 엔티티, 리파지토리 등등의 전술적 설계에서의 빌딩블록들을 다루는 것 이상으로 코드 자체가 아닌, 실생활에 더 밀접하게 연관된 것임을 알 수 있다. 개인적으로는 회사에서 실용적으로 DDD를 활용하고자 한다면, 분할된 컨텍스트를 어떻게 나눌 것이고, 그중에서도 핵심 도메인과, 서브 도메인은 어떻게 나눌 것인지, 분할된 컨텍스트 간의 관계를 어떻게 정의하고 운영할것인가, 분할된 컨텍스트 하의 모델들의 유비쿼터스 언어를 관리하고, 모델의 무결성이 없도록 할지에 대해서 더 집중하는게 좋다고 생각하고, 이게 DDD의 더 핵심적인 부분이라고 생각한다. 이를 전략적 설계라고 하고, 전술적 설계는 전략적 설계가 전제된 상태에서 고려되어야한다고 생각한다 | ||
| 5. 이처럼 DDD의 전략적 설계는 코드 이상으로, 더 큰 범위에서 사용이 될 수 있다. 회사를 기준으론 어떻게 팀을 나눌지, 핵심 팀과 서브 팀은 어떻게 되는지, 이 팀들을 어떤 기준으로 나누고, 관계를 설정할지 등등 이와 관련해서는 [팀토폴로지](https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=258906450) 라는 책을 보면 관련된 인사이트를 얻을 수 있다 |
There was a problem hiding this comment.
Consider rephrasing for clarity: "DDD's strategic design can be applied beyond code, such as in how companies organize teams, differentiate between core and sub-teams, and define relationships. The book 'Team Topologies' provides insights into this."
TaeHyoungKwon
force-pushed
the
thkwon-dddq-2
branch
from
606626f to
6408fb9
Compare
| 즉, 모델을 개선(refactor) 하지 않는 다는 말은 도메인과 관련된 구성원들이 가지는 암묵적 지식이 늘어난다는 말과도 동일하다고 볼 수 있을 것 같습니다. 그래서, 새로운 팀원이 온보딩을 해야할 때, 기존의 문서 혹은 코드와 더불어서, 해당 도메인의 담당자와 질문과 답변 과정을 또 거쳐야할 수밖에 없고 이는 계속적으로 반복되는것 같습니다. 이론적으로 보면, 도메인과 관련된 구성원들의 암묵적 지식들이 도메인 모델에 모두 반영이 되어있다면, 해당 도메인을 모르는 사람도, 도메인 모델만 보고도 이해할 수 있어야 하는데, 현실적으로는 이 도메인 모델이 잘 관리되지 않다보니, 암묵적 지식이 어쩔 수 없이 계속 생기게 되는 것 같습니다 | ||
|
|
||
| 논의 내용 | ||
| 1. 도메인 모델에 구성원들의 암묵적 지식을 모두 명시적으로 반영할 수 있도록 하는, 구체적인 방법이 있다면 어떤 것이 있을까요? 현실적이지 않은 방법이라도 본인이 생각하는 방법이 있다면 아이디어를 내서, 얘기해보면 좋을것 같습니다 |
There was a problem hiding this comment.
결국 latest version을 유지해야 하는 모델링 문서로 결론이 날 것 같습니다.
저도 태형님과 같은 상황을 많이 겪었지만, 결국 새로운 팀원이 스스로 도메인 지식을 이해하기에는 한계가 있기 때문에
문서를 보고(이 책의 내용으로 빌리면 도메인 모델) 1차로 이해하고,
암묵적 지식이 있는 구성원들과 대화를 통해 구체적으로 협력과 피드백을 받는 시간이 필요합니다.
새로운 팀원도 지식을 알게 되는 과정은 필연적일 수 밖에 없다고 봅니다.
그 과정에서 모메인 모델에서 미처 생각하지 못한 모델의 언어가 발견되면
또 latest vesion이 만들어지게 되겠죠.
There was a problem hiding this comment.
제 짧은 식견으로는, 문서가 유일한 방법이라고 생각합니다.
하지만 모든 구성원의 경험과 맥락을 온전히 문서로 옮기는 것은 불가능하기 때문에 지속적인 소통과 리뷰가 중요하다고 생각합니다.
개개인은 자신의 경험과 맥락 지식을 꾸준히 문서화하려는 노력이 필요하고, 조직적으로는 문서를 유지 보수 할 수 있는 문화를 만들어가는 것이 중요하다고 생각합니다.
비현실적인 방법을 생각해 봤는데, 모든 팀원이 모여서 작성된 코드를 한 줄씩 자연어로 번역해 보는 방식도 시도해 볼 수 있을 것 같습니다.
암묵적 지식이 녹아 있는 코드를 명시적으로 표현한다는 장점이 있을 것 같습니다.
There was a problem hiding this comment.
언젠가 AI를 이용하여 모델과 코드, 문서들을 분석해 문답이 가능하도록 학습시켜 해당 AI가 업데이트 된 암묵적 지식에 대한 퀴즈를 내고 팀원들이 답변을 하고 이를 취합해 공개하고 정답에 가까운 팀원들에게 보상을 주는 방식으로 소통하면 재밌을 것 같다는 생각이 들었습니다.
|
|
||
| 논의 내용 | ||
| 1. 도메인 모델에 구성원들의 암묵적 지식을 모두 명시적으로 반영할 수 있도록 하는, 구체적인 방법이 있다면 어떤 것이 있을까요? 현실적이지 않은 방법이라도 본인이 생각하는 방법이 있다면 아이디어를 내서, 얘기해보면 좋을것 같습니다 | ||
| 2. 위의 1번 에서 고민해본 방법이 현실적일 수도, 현실적이지 않을 수도 있을 것 같습니다. 현실적으로 가능하다면, 혹은 현실적으로 불가능하다면, 왜 그렇게 생각하는지 같이 얘기 나눠보면 좋을것 같습니다 |
There was a problem hiding this comment.
현실적으로 불가능한 요소는 관리의 부재 정도이지 않을까 싶은데
팀원의 관리 능력이 아닌 리더의 관리 능력이 더 큰 요소로 작용한다고 생각합니다.
여기서의 관리는 유지보수(maintenance)의 의미에 가깝다고 이해하시면 좋을 것 같습니다.
바쁜 업무 처리 시간을 쓰다 보면, 보통 관리하는데 쓰는 시간이 부족하므로
이런 저런 문서는 생성되지만, 생성되고 방치되는 경우가 많습니다.
따라서 그걸 유지보수 할 수 있는 프로세스, 관심, 리더의 적극성을 추가해 유지시켜 주는게 중요한 프로세스라고 생각합니다.
제가 초기에 실험적으로 했던 건
문서 작업 (설계+작업흐름설명)과 코드를 동시에 pull request 하는 장치를 해봤었는데 관리하는데 쉽지 않다는 걸 느꼈습니다.
지금은 사전 문서 작업을 공유하고, 그 내용을 연결시켜 pull request 요청을 하는 걸로 하고
나중에 볼 수 있는 문서라고 생각하는 건 "Document" tag를 달아서 꾸준히 보고 관리할 수 있게 하는 방법을 택하고 있습니다.
There was a problem hiding this comment.
빠듯한 일정과 부족한 동기부여 때문인 것 같습니다.
일정에 맞춰 개발하다 보면 문서는 고사하고 테스트 코드를 짤 시간도 부족한 경험이 다들 한번 씩 있으실 것 같습니다. 이것들이 반복되면 결국 문서는 잊혀지게 되는 것 같습니다.
가끔 누군가가 "우리 문서를 다시 잘 작성해 봅시다!" 하겠지만 결국 똑같은 상황의 연속일 것 같네요.
모든 회사가 그런 것은 아니지만 문서화가 고과 평가 요소인지 아닌지도 중요한 것 같습니다.
제 기억이 맞다면 작년에 우현님이 말씀해 주셨던 것 같은데, 리팩토링은 고과 평가 요소가 아니라는 말씀을 하셨던 것 같습니다. 리팩토링도 고과에 영향이 없는데, 하물며 문서화는 어떨까 하는 생각이 드네요.
| 1. 본인 혹은 회사에서 이런 분할된 컨텍스트를 정의해본 경험이 있다면 같이 얘기해보면 좋을 것 같습니다 | ||
| - 책에 분할된 컨텍스트를 나눠야한다는 말은 나옵니다. 하지만, 어떤 방식으로, 어떻게 나눠야한다는 말은 나오지 않습니다. 개인적으로 어떻게 나눠야한다는 내용이 나오지 않는 이유는 나누는 방법에 정답이 존재하지 않기 때문이 아닌가라는 생각입니다. | ||
| - 즉, 각 개인과 조직 마다 상황에 따라서 적절히 나누면 되는 것이라는 뜻 입니다. 실제로 저희 회사에서도 마이크로서비스를 정의할 때, 어떤 구체적인 방법을 사용하지 않습니다. 어떻게 나누는게 좋을지에 대해서 구성원들 간의 토론을 통해서, 컨텍스트 경계의 범위가 적절한지를 결정하고 있습니다 |
There was a problem hiding this comment.
저도 그걸 의식해서 정의하고 경계를 나눠 본 적은 없는 것 같습니다.
보통 협의 하다 보면 누군가 제안한 방식으로 모듈화(?)를 해보자라고 하고 그렇게 구분을 져서 만드는 것 같습니다.
그리고 태형님이 얘기한 대로 어떤 방식으로 어떻게 나눠야 한다는 규칙이 없다 보니
해당 작업을 하는 개발자가 인식한대로 하는 편이기도 합니다.
여기서 부터는 bounded context 내용입니다.
DDD에서는 bounded context는 모듈화랑 다른 개념으로 얘기합니다.
에릭 에반스의 도메인 주도 설계 책에서 얘기하는 bounded context는 위키북스 번역으로
제한된 컨텍스트라는 표현을 쓰고 있습니다.
여기서는 규모가 큰 프로젝트에는 하나의 모델이 아닌 여러 모델을 사용하므로
모델들 끼리의 하나의 context를 가지지 못할 때 경계를 짓는다 정도로 설명하고 있고
팀 조직끼리, 사용 방식에 따라, 물리적 데이터베이스에 따라 구분하라고 얘기하고 있습니다.
Bounded context는 결국 팀 조직간 모델의 경계를 긋고 각자 구현을 가져가므로
필연적으로 모델의 균열이 생기고 이를 동기화 하는 작업이 생기게 되는 것도 언급하고 있습니다.
There was a problem hiding this comment.
도메인의 생명주기가 다른 도메인에 영향을 받는지, 홀로 살아남을 수 있는 도메인인지 등의 느낌에 의존하는 것 같습니다.
저의 모든 경험은 혼자 진행하는 사이드 프로젝트에서 경험해 본 것이기 때문에 간단한 도메인들뿐이어서 아직까지는 크게 문제가 되지는 않는 것 같네요.
| 1. 6장 제목은 오늘날 DDD는 중요하다 입니다. 이번에 DDD 책을 읽고, DDD가 중요하다고 느끼셨나요? | ||
| - 일단 저는 DDD 자체가 별로 중요하다고는 생각진 않습니다. 쉽게 말하면, 몰라도 된다고 생각 합니다. 짧은 경험이지만, 회사에서 DDD에서 말하는 개념과 키워드들을 몰랐었도 일을 하는데 전혀 문제가 없었기 때문입니다. 이것은 저를 제외하고도 다른 분들도 마찬가지 였습니다 어떻게 보면 DDD에서 하는 말들이 전부 상식적인 말들이기 때문에 굳이 이걸 이론적으로 정리하지 않아도, 회사 구성원들끼리 합리적인 결정을 위한 토론과 논의 과정에서 무의식적으로 적용하게 되었기 때문이 아닐까 생각됩니다. | ||
| - 오히려, 이번에 DDD를 배웠다고 해서, 무리하게 회사에서 팀원들을 설득하려고 하는게 더 위험한 행동이 아닐까 라는 생각을 해봅니다. 굳이 필요없는 것을 내가 봤을 때 좋아 보인다고, 적용하는 것은 이기적인게 아닌가 라는 생각이 듭니다 | ||
| - 다만, DDD에서 배운 키워드들과 개념들은 제 개인적으로 도움이 많이 되었다고 생각합니다 이정도로 저는 매우 만족스럽습니다 |
There was a problem hiding this comment.
저는 중요하다고 생각합니다.
물론 지속적인 서비스 개발의 관점에서도 도메인은 필요하겠지만
처음부터 모르는 도메인을 알아가는 과정을 포함한 소프트웨어 개발이라면 더 중요하다고 생각합니다.
그리고 DDD가 얘기하는 전략도 중요할 수 있지만
그것 보다도 알아야 할 도메인에 대해 탐구하고 학습할 자세를 가지는 게 더 중요하다고 봅니다.
제가 좋아하는 주제에서 DDD가 추가된 걸
에릭 에반스의 책을 읽으면서 리뷰를 남겨뒀었습니다.
계속해서 발전해 나갈 도메인 모델이라면 적극적으로 도메인을 이해하려는 마음이 필요할 것 같습니다.
There was a problem hiding this comment.
너무나도 당연하고 모두가 동의하는 명제인 "개발은 도메인 문제를 해결하는 일이다."라는 DDD의 철학은 매우 중요하다고 생각합니다.
저는 DDD라는 방법론을 추천하는 것이 아니라 교양서라는 관점에서 DDD 책을 한번씩이라도 읽어보기를 권할 것 같습니다.
| 즉, 모델을 개선(refactor) 하지 않는 다는 말은 도메인과 관련된 구성원들이 가지는 암묵적 지식이 늘어난다는 말과도 동일하다고 볼 수 있을 것 같습니다. 그래서, 새로운 팀원이 온보딩을 해야할 때, 기존의 문서 혹은 코드와 더불어서, 해당 도메인의 담당자와 질문과 답변 과정을 또 거쳐야할 수밖에 없고 이는 계속적으로 반복되는것 같습니다. 이론적으로 보면, 도메인과 관련된 구성원들의 암묵적 지식들이 도메인 모델에 모두 반영이 되어있다면, 해당 도메인을 모르는 사람도, 도메인 모델만 보고도 이해할 수 있어야 하는데, 현실적으로는 이 도메인 모델이 잘 관리되지 않다보니, 암묵적 지식이 어쩔 수 없이 계속 생기게 되는 것 같습니다 | ||
|
|
||
| 논의 내용 | ||
| 1. 도메인 모델에 구성원들의 암묵적 지식을 모두 명시적으로 반영할 수 있도록 하는, 구체적인 방법이 있다면 어떤 것이 있을까요? 현실적이지 않은 방법이라도 본인이 생각하는 방법이 있다면 아이디어를 내서, 얘기해보면 좋을것 같습니다 |
There was a problem hiding this comment.
제 짧은 식견으로는, 문서가 유일한 방법이라고 생각합니다.
하지만 모든 구성원의 경험과 맥락을 온전히 문서로 옮기는 것은 불가능하기 때문에 지속적인 소통과 리뷰가 중요하다고 생각합니다.
개개인은 자신의 경험과 맥락 지식을 꾸준히 문서화하려는 노력이 필요하고, 조직적으로는 문서를 유지 보수 할 수 있는 문화를 만들어가는 것이 중요하다고 생각합니다.
비현실적인 방법을 생각해 봤는데, 모든 팀원이 모여서 작성된 코드를 한 줄씩 자연어로 번역해 보는 방식도 시도해 볼 수 있을 것 같습니다.
암묵적 지식이 녹아 있는 코드를 명시적으로 표현한다는 장점이 있을 것 같습니다.
|
|
||
| 논의 내용 | ||
| 1. 도메인 모델에 구성원들의 암묵적 지식을 모두 명시적으로 반영할 수 있도록 하는, 구체적인 방법이 있다면 어떤 것이 있을까요? 현실적이지 않은 방법이라도 본인이 생각하는 방법이 있다면 아이디어를 내서, 얘기해보면 좋을것 같습니다 | ||
| 2. 위의 1번 에서 고민해본 방법이 현실적일 수도, 현실적이지 않을 수도 있을 것 같습니다. 현실적으로 가능하다면, 혹은 현실적으로 불가능하다면, 왜 그렇게 생각하는지 같이 얘기 나눠보면 좋을것 같습니다 |
There was a problem hiding this comment.
빠듯한 일정과 부족한 동기부여 때문인 것 같습니다.
일정에 맞춰 개발하다 보면 문서는 고사하고 테스트 코드를 짤 시간도 부족한 경험이 다들 한번 씩 있으실 것 같습니다. 이것들이 반복되면 결국 문서는 잊혀지게 되는 것 같습니다.
가끔 누군가가 "우리 문서를 다시 잘 작성해 봅시다!" 하겠지만 결국 똑같은 상황의 연속일 것 같네요.
모든 회사가 그런 것은 아니지만 문서화가 고과 평가 요소인지 아닌지도 중요한 것 같습니다.
제 기억이 맞다면 작년에 우현님이 말씀해 주셨던 것 같은데, 리팩토링은 고과 평가 요소가 아니라는 말씀을 하셨던 것 같습니다. 리팩토링도 고과에 영향이 없는데, 하물며 문서화는 어떨까 하는 생각이 드네요.
| 1. 본인 혹은 회사에서 이런 분할된 컨텍스트를 정의해본 경험이 있다면 같이 얘기해보면 좋을 것 같습니다 | ||
| - 책에 분할된 컨텍스트를 나눠야한다는 말은 나옵니다. 하지만, 어떤 방식으로, 어떻게 나눠야한다는 말은 나오지 않습니다. 개인적으로 어떻게 나눠야한다는 내용이 나오지 않는 이유는 나누는 방법에 정답이 존재하지 않기 때문이 아닌가라는 생각입니다. | ||
| - 즉, 각 개인과 조직 마다 상황에 따라서 적절히 나누면 되는 것이라는 뜻 입니다. 실제로 저희 회사에서도 마이크로서비스를 정의할 때, 어떤 구체적인 방법을 사용하지 않습니다. 어떻게 나누는게 좋을지에 대해서 구성원들 간의 토론을 통해서, 컨텍스트 경계의 범위가 적절한지를 결정하고 있습니다 |
There was a problem hiding this comment.
도메인의 생명주기가 다른 도메인에 영향을 받는지, 홀로 살아남을 수 있는 도메인인지 등의 느낌에 의존하는 것 같습니다.
저의 모든 경험은 혼자 진행하는 사이드 프로젝트에서 경험해 본 것이기 때문에 간단한 도메인들뿐이어서 아직까지는 크게 문제가 되지는 않는 것 같네요.
| 1. 6장 제목은 오늘날 DDD는 중요하다 입니다. 이번에 DDD 책을 읽고, DDD가 중요하다고 느끼셨나요? | ||
| - 일단 저는 DDD 자체가 별로 중요하다고는 생각진 않습니다. 쉽게 말하면, 몰라도 된다고 생각 합니다. 짧은 경험이지만, 회사에서 DDD에서 말하는 개념과 키워드들을 몰랐었도 일을 하는데 전혀 문제가 없었기 때문입니다. 이것은 저를 제외하고도 다른 분들도 마찬가지 였습니다 어떻게 보면 DDD에서 하는 말들이 전부 상식적인 말들이기 때문에 굳이 이걸 이론적으로 정리하지 않아도, 회사 구성원들끼리 합리적인 결정을 위한 토론과 논의 과정에서 무의식적으로 적용하게 되었기 때문이 아닐까 생각됩니다. | ||
| - 오히려, 이번에 DDD를 배웠다고 해서, 무리하게 회사에서 팀원들을 설득하려고 하는게 더 위험한 행동이 아닐까 라는 생각을 해봅니다. 굳이 필요없는 것을 내가 봤을 때 좋아 보인다고, 적용하는 것은 이기적인게 아닌가 라는 생각이 듭니다 | ||
| - 다만, DDD에서 배운 키워드들과 개념들은 제 개인적으로 도움이 많이 되었다고 생각합니다 이정도로 저는 매우 만족스럽습니다 |
There was a problem hiding this comment.
너무나도 당연하고 모두가 동의하는 명제인 "개발은 도메인 문제를 해결하는 일이다."라는 DDD의 철학은 매우 중요하다고 생각합니다.
저는 DDD라는 방법론을 추천하는 것이 아니라 교양서라는 관점에서 DDD 책을 한번씩이라도 읽어보기를 권할 것 같습니다.
| 즉, 모델을 개선(refactor) 하지 않는 다는 말은 도메인과 관련된 구성원들이 가지는 암묵적 지식이 늘어난다는 말과도 동일하다고 볼 수 있을 것 같습니다. 그래서, 새로운 팀원이 온보딩을 해야할 때, 기존의 문서 혹은 코드와 더불어서, 해당 도메인의 담당자와 질문과 답변 과정을 또 거쳐야할 수밖에 없고 이는 계속적으로 반복되는것 같습니다. 이론적으로 보면, 도메인과 관련된 구성원들의 암묵적 지식들이 도메인 모델에 모두 반영이 되어있다면, 해당 도메인을 모르는 사람도, 도메인 모델만 보고도 이해할 수 있어야 하는데, 현실적으로는 이 도메인 모델이 잘 관리되지 않다보니, 암묵적 지식이 어쩔 수 없이 계속 생기게 되는 것 같습니다 | ||
|
|
||
| 논의 내용 | ||
| 1. 도메인 모델에 구성원들의 암묵적 지식을 모두 명시적으로 반영할 수 있도록 하는, 구체적인 방법이 있다면 어떤 것이 있을까요? 현실적이지 않은 방법이라도 본인이 생각하는 방법이 있다면 아이디어를 내서, 얘기해보면 좋을것 같습니다 |
There was a problem hiding this comment.
언젠가 AI를 이용하여 모델과 코드, 문서들을 분석해 문답이 가능하도록 학습시켜 해당 AI가 업데이트 된 암묵적 지식에 대한 퀴즈를 내고 팀원들이 답변을 하고 이를 취합해 공개하고 정답에 가까운 팀원들에게 보상을 주는 방식으로 소통하면 재밌을 것 같다는 생각이 들었습니다.
책은 빠르게 읽었는데, 이번에도 정리하는데 오래걸렸네요 늦어서 송구합니다 Close #511