Conversation
tttghost
requested review from
jongfeel,
TaeHyoungKwon,
jintaeyeong,
hemil0102,
ymkim97,
fkdl0048 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 @tttghost, 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 contains notes on the first three chapters of the book 'Domain-Driven Design Quickly' by tttghost. The notes cover key concepts from each chapter, including the importance of ubiquitous language, model-driven design, and building domain knowledge. The author also poses questions for discussion related to ubiquitous language and experiences with domain-driven design.
Highlights
- Chapter 1: What is Domain-Driven Design?: Summarizes the essence of Domain-Driven Design (DDD), emphasizing the importance of understanding the domain and collaborating with domain experts. It highlights the need to move beyond code-centric views and focus on the underlying domain.
- Chapter 2: Ubiquitous Language: Explains the concept of ubiquitous language, which involves creating a common language between different roles in a project (developers, domain experts, etc.) to avoid misunderstandings and ensure everyone is on the same page.
- Chapter 3: Model-Driven Design: Discusses the importance of translating the domain model into code effectively. It touches upon the challenges of separating analysis models from code design and advocates for a close relationship between the two.
Changelog
Click here to see the changelog
- 2025/Domain-Driven Design Quickly/tttghost/Chapter1.md
- Added notes summarizing Chapter 1 of 'Domain-Driven Design Quickly'.
- Included discussion questions about ubiquitous language and DDD experience.
- Explained the importance of domain knowledge and collaboration with experts.
- 2025/Domain-Driven Design Quickly/tttghost/Chapter2.md
- Added notes summarizing Chapter 2 of 'Domain-Driven Design Quickly'.
- Defined ubiquitous language and its role in project communication.
- Emphasized the need for a common language based on the domain model.
- 2025/Domain-Driven Design Quickly/tttghost/Chapter3.md
- Added notes summarizing Chapter 3 of 'Domain-Driven Design Quickly'.
- Discussed the importance of translating the domain model into code.
- Highlighted the relationship between analysis models and code design.
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.
In domains complex, where knowledge resides,
A common tongue, where clarity presides.
With models as guides, and code as our art,
Domain-Driven Design, a brand new start.
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 introduces three new markdown files that summarize key concepts from the book 'Domain-Driven Design Quickly'. The content provides a good overview of Domain-Driven Design principles, ubiquitous language, and model-driven design. The writing style is clear and easy to understand. However, there are a few areas where the content could be improved for clarity and completeness.
Merge Readiness
The pull request is in good shape to be merged. The content is informative and well-written. However, consider the suggestions provided in the review comments to further enhance the clarity and completeness of the content. I am unable to directly approve the pull request, and recommend that others review and approve this code before merging.
| 자동차생산에 대해 비유적으로 설명한 것이 있는데 자동차가 수많은 부품에 의해 만들어지는 과정 단순 조립품으로 볼 수도 있지만 | ||
| 그것은 자동차 이지 좋은 자동차는 아니다. |
There was a problem hiding this comment.
Consider rephrasing this sentence for better clarity. For example: 'The process of building a car from numerous parts can be viewed as a simple assembly, but that doesn't make it a good car.'
| 자동차생산에 대해 비유적으로 설명한 것이 있는데 자동차가 수많은 부품에 의해 만들어지는 과정 단순 조립품으로 볼 수도 있지만 | |
| 그것은 자동차 이지 좋은 자동차는 아니다. | |
| 자동차생산에 대해 비유적으로 설명한 것이 있는데 자동차가 수많은 부품에 의해 만들어지는 과정을 단순 조립품으로 볼 수도 있지만 | |
| 그것만으로는 좋은 자동차라고 할 수 없습니다. |
| 소프트웨어 개발도 이와 유사하다. | ||
| 도메인에 대한 깊은 지식 없이 복잡한 소프트웨어를 만드는 것은 불가능하다. | ||
|
|
||
| 복잡한 은행 소프트웨어를 만드는데 해당분야의 도메인지식이 있어야 만들 수 있다. 소프트웨어를 만들 때 소프트웨어가 어떤 도메인에 의해 동작하는지 집중해야 한다. 우리는 해당분야의 도메인 지식이 없을 수 있다. 이럴땐 해당분야의 도메인지식이 있는 전문가와 많은 이야기를 나누면서 도메인에 대해 많은 것을 배워야 한다. 이 과정에서 가공되지 않은 수많은 데이터들에 대해 들을 수 있다. 각자가 보는 청사진이 다르기에 초기엔 불완전 할 수 있다. 그러나 계속 이 과정을 반복하다 보면 점점더 명확해진다. 이러한 추상화 과정은 머릿속에만 있는 것이 아니라 같이 청사진을 그릴 필요가 있다. 이때 다이어그램으로 모델을 그리며 서로가 생각하는 부분에 대해 이야기 하는 것이다. |
There was a problem hiding this comment.
Consider adding a sentence or two about the importance of documenting these discussions and decisions. This could include using tools like wikis or shared documents to capture the evolving understanding of the domain.
| 복잡한 은행 소프트웨어를 만드는데 해당분야의 도메인지식이 있어야 만들 수 있다. 소프트웨어를 만들 때 소프트웨어가 어떤 도메인에 의해 동작하는지 집중해야 한다. 우리는 해당분야의 도메인 지식이 없을 수 있다. 이럴땐 해당분야의 도메인지식이 있는 전문가와 많은 이야기를 나누면서 도메인에 대해 많은 것을 배워야 한다. 이 과정에서 가공되지 않은 수많은 데이터들에 대해 들을 수 있다. 각자가 보는 청사진이 다르기에 초기엔 불완전 할 수 있다. 그러나 계속 이 과정을 반복하다 보면 점점더 명확해진다. 이러한 추상화 과정은 머릿속에만 있는 것이 아니라 같이 청사진을 그릴 필요가 있다. 이때 다이어그램으로 모델을 그리며 서로가 생각하는 부분에 대해 이야기 하는 것이다. | |
| 복잡한 은행 소프트웨어를 만드는데 해당분야의 도메인지식이 있어야 만들 수 있다. 소프트웨어를 만들 때 소프트웨어가 어떤 도메인에 의해 동작하는지 집중해야 한다. 우리는 해당분야의 도메인 지식이 없을 수 있다. 이럴땐 해당분야의 도메인지식이 있는 전문가와 많은 이야기를 나누면서 도메인에 대해 많은 것을 배워야 한다. 이 과정에서 가공되지 않은 수많은 데이터들에 대해 들을 수 있다. 각자가 보는 청사진이 다르기에 초기엔 불완전 할 수 있다. 그러나 계속 이 과정을 반복하다 보면 점점더 명확해진다. 이러한 추상화 과정은 머릿속에만 있는 것이 아니라 같이 청사진을 그릴 필요가 있다. 이때 다이어그램으로 모델을 그리며 서로가 생각하는 부분에 대해 이야기 하는 것이다. 이러한 논의 과정과 결정 사항을 문서화하는 것이 중요합니다. |
| 각각의 방법론은 장단점이 있는데 폭포수모델은 처음부터 완벽하게 일을 하려고 하기 때문에 분석마비 라는 현상이 있을 수 있고 | ||
| 또 애자일은 빠르게 피드백을 반영하여 개발하는 장점이 있지만 견고하게 설계하지 않고 잦은 리팩토링을 수행하여 개발한다면 스파게티코드를 양산할 우려가 있다. |
There was a problem hiding this comment.
Consider rephrasing for clarity. For example: 'The waterfall model can suffer from 'analysis paralysis' due to its attempt to perfect the initial design. Agile, while offering rapid feedback, can lead to 'spaghetti code' if frequent refactoring is not accompanied by solid design principles.'
| 각각의 방법론은 장단점이 있는데 폭포수모델은 처음부터 완벽하게 일을 하려고 하기 때문에 분석마비 라는 현상이 있을 수 있고 | |
| 또 애자일은 빠르게 피드백을 반영하여 개발하는 장점이 있지만 견고하게 설계하지 않고 잦은 리팩토링을 수행하여 개발한다면 스파게티코드를 양산할 우려가 있다. | |
| 각각의 방법론은 장단점이 있는데 폭포수모델은 처음부터 완벽하게 일을 하려고 하기 때문에 분석마비 라는 현상이 있을 수 있고 | |
| 또 애자일은 빠르게 피드백을 반영하여 개발하는 장점이 있지만 견고한 설계 없이 잦은 리팩토링을 수행하면 스파게티 코드를 양산할 우려가 있습니다. |
| 공통의 프로젝트를 진행하지만 각 역할군 마다 사용하는 언어가 다르고 바라보는 시각이 다르기에 언어가 제각각 일 수 밖에 없다. | ||
| 이때 필요한 것이 유비쿼터스 언어이다. | ||
|
|
||
| 유비쿼터스 언어, 즉 공통언어를 만들지 않고 대화를 하다보면 프로젝트가 결국 산으로 가기 쉽상이다. |
There was a problem hiding this comment.
Consider rephrasing for better flow. For example: 'Without a ubiquitous language, communication breakdowns can easily derail a project.'
| 유비쿼터스 언어, 즉 공통언어를 만들지 않고 대화를 하다보면 프로젝트가 결국 산으로 가기 쉽상이다. | |
| 유비쿼터스 언어, 즉 공통언어를 만들지 않고 대화를 하다보면 프로젝트가 결국 산으로 가기 쉽습니다. |
| @@ -0,0 +1,17 @@ | |||
| # 3장 모델 주도 설계 | |||
| 앞서 도메인을 중심으로 한 소프트웨어 개발하였다고 하면 | |||
| 다이어그램이나 유비쿼터스 언어 등으로 도메인전문과와 함께 최고의 모델을 만들었다고 치자. | |||
There was a problem hiding this comment.
Consider rephrasing for clarity. For example: 'Let's assume we've developed a software application centered around the domain, and we've collaborated with domain experts to create an excellent model using diagrams and a ubiquitous language.'
| 다이어그램이나 유비쿼터스 언어 등으로 도메인전문과와 함께 최고의 모델을 만들었다고 치자. | |
| 다이어그램이나 유비쿼터스 언어 등으로 도메인전문과와 함께 최고의 모델을 만들었다고 가정해 봅시다. |
| @@ -0,0 +1,46 @@ | |||
| 논의내용 | |||
| - 유비쿼터스 언어에 대한 중요성을 어느정도 생각하고 있으신가요? | |||
There was a problem hiding this comment.
소통의 도구의 일부로 생각하고 있기 때문에 매우 중요하게 보고 있다고 말할 수 있을 것 같습니다
There was a problem hiding this comment.
완벽하게 일치하는 예는 아니지만 비슷한 맥락으로 몽미가 있을 것 같습니다.
There was a problem hiding this comment.
(드립입니다. 진지하게 받아들이지 마세요.)
그래서 우린 이걸 수박이라고 하기로 했어요. 사회적 약속이라서요.
| @@ -0,0 +1,46 @@ | |||
| 논의내용 | |||
| - 유비쿼터스 언어에 대한 중요성을 어느정도 생각하고 있으신가요? | |||
| - 도메인주도 설계 방식으로 개발한 사례가 있으신가요? | |||
There was a problem hiding this comment.
저는 없습니다 도메인주도 설계의 개념들을 차용하여서, 프로젝트에 적용한 경우는 많습니다
There was a problem hiding this comment.
저도 DDD로 개발했다. 라고 말할 수는 없지만 DDD의 핵심 개념 중 "유비쿼터스 언어", "바운디드 컨텍스트" 등은 프로젝트에 적용하고 있습니다.
| @@ -0,0 +1,46 @@ | |||
| 논의내용 | |||
| - 유비쿼터스 언어에 대한 중요성을 어느정도 생각하고 있으신가요? | |||
There was a problem hiding this comment.
완벽하게 일치하는 예는 아니지만 비슷한 맥락으로 몽미가 있을 것 같습니다.
| @@ -0,0 +1,46 @@ | |||
| 논의내용 | |||
| - 유비쿼터스 언어에 대한 중요성을 어느정도 생각하고 있으신가요? | |||
| - 도메인주도 설계 방식으로 개발한 사례가 있으신가요? | |||
There was a problem hiding this comment.
저도 DDD로 개발했다. 라고 말할 수는 없지만 DDD의 핵심 개념 중 "유비쿼터스 언어", "바운디드 컨텍스트" 등은 프로젝트에 적용하고 있습니다.
| @@ -0,0 +1,46 @@ | |||
| 논의내용 | |||
| - 유비쿼터스 언어에 대한 중요성을 어느정도 생각하고 있으신가요? | |||
There was a problem hiding this comment.
사실 실무에서 다양한 직군의 사람들과 얘기하다 보면 같은 용어를 다르게 해석하는 일이 많이 일어납니다.
유비쿼터스 언어가 필요하다! 라고 명시적으로 얘기하는 사람은 못봤지만 업무 진행하면서 암묵적으로 다들 물어보고 이해하고 하면서 맞춰 나가는 것 같긴 합니다.
| @@ -0,0 +1,46 @@ | |||
| 논의내용 | |||
| - 유비쿼터스 언어에 대한 중요성을 어느정도 생각하고 있으신가요? | |||
| - 도메인주도 설계 방식으로 개발한 사례가 있으신가요? | |||
There was a problem hiding this comment.
자도 태형님과 같은데 이게 도메인 주도 설계 방식이다 라고 한 건 없고 그 개념을 구체화 시켜서 만든게 이 설계고 코드가 이렇다 라고 한 건 있습니다.
| @@ -0,0 +1,46 @@ | |||
| 논의내용 | |||
| - 유비쿼터스 언어에 대한 중요성을 어느정도 생각하고 있으신가요? | |||
There was a problem hiding this comment.
이전에 게임 관련 회의를 할 때도 같은 단어를 사용하지만 미묘하게 서로 다른 것을 이야기하는 경우가 있었고 이는 나중에 큰 차이를 만들었던 기억이 있습니다. 의사소통에 있어 유비쿼터스 언어와 같이 공통된 의미의 같은 것을 상상할 수 있는 언어를 만드는 것이 굉장히 중요하다고 생각이 들었습니다.
도메인 주도 설계에 대해 어렵지만 쉽게 다가갈 수 있는 느낌으로 읽었습니다.
특히 유비쿼터스 언어는 이미 실제로 사용하고 있었던 부분인데 이 부분에 대해 좀더 도메인 전문가와
이야기 할 때 어떤식으로 접근해야 할 지에 대해 생각해 볼 수 있는 부분이었습니다.
그 외에 다른 부분들은 좀 어려워서 다시 보며 이해해보면 좋을 것 같습니다.