Conversation
aquamagic9
requested review from
jongfeel,
TaeHyoungKwon,
jintaeyeong,
hemil0102,
ymkim97,
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 @aquamagic9, 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 and summaries from reading the first three chapters of the book 'Domain-Driven Design Quickly' by aquamagic9. The summaries cover key concepts such as the importance of domain-driven design, ubiquitous language, and model-driven design. The author also includes personal thoughts and discussion points related to the content.
Highlights
- Chapter 1 Summary: Summarizes the core principles of Domain-Driven Design (DDD), emphasizing the importance of aligning software with the business domain and effectively modeling complex concepts.
- Chapter 2 Summary: Explains the concept of a Ubiquitous Language in DDD, highlighting the need for a common language between domain experts and developers to ensure clear communication and a shared understanding of the model.
- Chapter 3 Summary: Discusses Model-Driven Design, emphasizing the importance of a close relationship between the domain model and the code, and introduces concepts like layered architecture, entities, value objects, services, modules, aggregates, factories, and repositories.
- Discussion Points: Raises questions about the practical application of waterfall and agile methodologies in real-world scenarios, and how to address the challenges associated with each approach.
- Personal Reflections: Includes personal reflections on the material, such as the realization that software development involves personal style and talent, and the importance of close alignment between the domain and the software.
Changelog
- 2025/Domain-Driven Design Quickly/aquamagic9/Chapter1.md
- Added a summary of Chapter 1, '도메인 주도 설계란 무엇인가?' (What is Domain-Driven Design?).
- Included discussion points about waterfall vs. agile methodologies and their practical application.
- Added personal thoughts and reflections on the chapter's content.
- 2025/Domain-Driven Design Quickly/aquamagic9/Chapter2.md
- Added a summary of Chapter 2, '유비쿼터스 언어' (Ubiquitous Language).
- Explained the importance of a common language between domain experts and developers.
- 2025/Domain-Driven Design Quickly/aquamagic9/Chapter3.md
- Added a summary of Chapter 3, '모델 주도 설계' (Model-Driven Design).
- Introduced key concepts such as layered architecture, entities, value objects, services, modules, 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 the name of the book that introduced Domain-Driven Design to the software development community?
Click here for the answer
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans.
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 of the book 'Domain-Driven Design Quickly' by capturing key concepts from chapters 1, 2, and 3. The content effectively highlights the importance of domain-driven design, ubiquitous language, and model-driven design. The summary also includes personal thoughts and discussion points, which add a reflective aspect to the material. Overall, this is a well-structured and informative summary of the initial chapters of the book.
Merge Readiness
The pull request is a good summary of the first three chapters of 'Domain-Driven Design Quickly'. There are no critical or high severity issues. I am unable to directly approve the pull request, and other reviewers should review and approve this code before merging.
| ### 논의내용 | ||
| 책에서 소프트웨어를 설계하는 방법의 예시로 폭포수 설계 방법과 애자일 방법론이 나옵니다. 폭포수 설계의 경우에는 지식이 한 방향으로 흐르며 모든 요구사항을 프로젝트 초기에 확정지으려고 시도하며 분석 마비와 같은 문제점이 나타납니다. 애자일 방법론의 경우에는 구현을 용이하게 변경할 수 있도록 하며 수많은 리팩토링을 통해 개발을 반복적으로 수행하지만 견고한 원칙이 없이 지속적인 리팩토링이 수행되면 이해하기 어려운 코드가 양산됩니다. | ||
|
|
||
| 실제 현업에서 위와 같은 방법들을 사용하는지 궁금하고 다른 방법이 있다면 어떤 방법을 사용하는지 궁금합니다. 또한 여러 방법들 중 왜 그 방법을 선택하여 사용하였는지도 궁금합니다. | ||
|
|
||
| 이런 설계 원칙들이 각각 문제점이 존재하는데 현업에서 해당 문제점이 발견되었을 때 어떻게 대처를 하는지 궁금합니다. |
There was a problem hiding this comment.
실제 현업에서 위와 같은 방법들을 사용하는지 궁금하고 다른 방법이 있다면 어떤 방법을 사용하는지 궁금합니다.
제가 일하고 있는 현업 기준으로 위해서 말씀주신, 폭포수, 애자일을 모두 활용합니다 그외의 어떤 방법론이 있는지는 잘 모르겠네요
다만, 폭포수와 애자일과 관련해서 적어주신 내용에 대해서는 개인적으로 조금 동의하기 어려운 부분들이 있습니다
한가지 제가 말씀드릴 수 있는 것은 현업에서 일을할 때, 폭포수인지, 애자일인지 는 중요한거 같지 않다는 것이고, 구체적인 방법론이 어떻든 주어진 일을 일단은 잘해내는 것 그 자체가 중요한 것 같습니다
또한 여러 방법들 중 왜 그 방법을 선택하여 사용하였는지도 궁금합니다.
저희 회사에서는 흔히 말하는 애자일에서의 스크럼을 과거에 많이 사용 했었는데요, 2주 간격으로 스프린트를 돌면서, 제품 개발의 피드백 주기를 빠르게 가져가는 전략을 가져가기 위해서 사용 했었습니다.
There was a problem hiding this comment.
저는 정부사업 프로젝트를 진행하다보니 애자일을 경험해보지는 못했습니다.
There was a problem hiding this comment.
저는 주로 국책과제 쪽으로 프로젝트를 진행하다보니 애자일 방법론으로 개발을 한 것 같았습니다.
빠르게 개발한다? 라는 측면에서 애자일 방법론으로 알고 있었는데 그건 아니었더군요.
책 내용 중 너무 짧게 피드백이 오고가서 결국 스파게티코드같이 되어버린 경우도 더러 있었구요.
애자일방식인진 모르겠으나 책에서 나온 애자일방식의 단점인 형태로 프로젝트가 진행된 적이 있었습니다.
| ### 논의내용 | ||
| 책에서 소프트웨어를 설계하는 방법의 예시로 폭포수 설계 방법과 애자일 방법론이 나옵니다. 폭포수 설계의 경우에는 지식이 한 방향으로 흐르며 모든 요구사항을 프로젝트 초기에 확정지으려고 시도하며 분석 마비와 같은 문제점이 나타납니다. 애자일 방법론의 경우에는 구현을 용이하게 변경할 수 있도록 하며 수많은 리팩토링을 통해 개발을 반복적으로 수행하지만 견고한 원칙이 없이 지속적인 리팩토링이 수행되면 이해하기 어려운 코드가 양산됩니다. | ||
|
|
||
| 실제 현업에서 위와 같은 방법들을 사용하는지 궁금하고 다른 방법이 있다면 어떤 방법을 사용하는지 궁금합니다. 또한 여러 방법들 중 왜 그 방법을 선택하여 사용하였는지도 궁금합니다. | ||
|
|
||
| 이런 설계 원칙들이 각각 문제점이 존재하는데 현업에서 해당 문제점이 발견되었을 때 어떻게 대처를 하는지 궁금합니다. |
There was a problem hiding this comment.
저는 정부사업 프로젝트를 진행하다보니 애자일을 경험해보지는 못했습니다.
| ### 논의내용 | ||
| 책에서 소프트웨어를 설계하는 방법의 예시로 폭포수 설계 방법과 애자일 방법론이 나옵니다. 폭포수 설계의 경우에는 지식이 한 방향으로 흐르며 모든 요구사항을 프로젝트 초기에 확정지으려고 시도하며 분석 마비와 같은 문제점이 나타납니다. 애자일 방법론의 경우에는 구현을 용이하게 변경할 수 있도록 하며 수많은 리팩토링을 통해 개발을 반복적으로 수행하지만 견고한 원칙이 없이 지속적인 리팩토링이 수행되면 이해하기 어려운 코드가 양산됩니다. | ||
|
|
||
| 실제 현업에서 위와 같은 방법들을 사용하는지 궁금하고 다른 방법이 있다면 어떤 방법을 사용하는지 궁금합니다. 또한 여러 방법들 중 왜 그 방법을 선택하여 사용하였는지도 궁금합니다. | ||
|
|
||
| 이런 설계 원칙들이 각각 문제점이 존재하는데 현업에서 해당 문제점이 발견되었을 때 어떻게 대처를 하는지 궁금합니다. |
There was a problem hiding this comment.
저는 주로 국책과제 쪽으로 프로젝트를 진행하다보니 애자일 방법론으로 개발을 한 것 같았습니다.
빠르게 개발한다? 라는 측면에서 애자일 방법론으로 알고 있었는데 그건 아니었더군요.
책 내용 중 너무 짧게 피드백이 오고가서 결국 스파게티코드같이 되어버린 경우도 더러 있었구요.
애자일방식인진 모르겠으나 책에서 나온 애자일방식의 단점인 형태로 프로젝트가 진행된 적이 있었습니다.
| 책에서 소프트웨어를 설계하는 방법의 예시로 폭포수 설계 방법과 애자일 방법론이 나옵니다. 폭포수 설계의 경우에는 지식이 한 방향으로 흐르며 모든 요구사항을 프로젝트 초기에 확정지으려고 시도하며 분석 마비와 같은 문제점이 나타납니다. 애자일 방법론의 경우에는 구현을 용이하게 변경할 수 있도록 하며 수많은 리팩토링을 통해 개발을 반복적으로 수행하지만 견고한 원칙이 없이 지속적인 리팩토링이 수행되면 이해하기 어려운 코드가 양산됩니다. | ||
|
|
||
| 실제 현업에서 위와 같은 방법들을 사용하는지 궁금하고 다른 방법이 있다면 어떤 방법을 사용하는지 궁금합니다. 또한 여러 방법들 중 왜 그 방법을 선택하여 사용하였는지도 궁금합니다. | ||
|
|
||
| 이런 설계 원칙들이 각각 문제점이 존재하는데 현업에서 해당 문제점이 발견되었을 때 어떻게 대처를 하는지 궁금합니다. |
There was a problem hiding this comment.
저도 다른 관점을 말씀드리면, 초기에 애자일과 XP(eXtreme programming)을 접하면서 원칙주의자(?) 같은 성향으로 업무를 진행했던 경험이 있었습니다.
지금 돌이켜 보면 그런 방법론이 좋다, 나쁘다의 접근은 그렇게 중요하진 않습니다.
일하는 방식은 만들어 나가는 거고, 거기에 폭포수로 하면 안된다, 애자일을 끼얹어야 잘 돌아간다는 원칙주의자의 얘기에 가깝다고 여겨집니다.
애자일 이라는 단어를 빼고, 진짜 애자일 원칙을 드러내지 않고 실천해서 전파할 수 있는 사람이 개발 방법론에 대해 잘 파악하고 있는 사람이 아닌가 하는 생각입니다.
그리고 전 애자일 좋아합니다. 함께 자라기 책에서 언급한 협력과 피드백 꼭 해야 한다는 입장입니다.
하지만 애자일 방법론을 써야 개발을 잘할 수 있다 쪽은 좋아하지 않습니다.
매일 고객에게 가치를 전하라
이걸 개발하는 사람들끼리 실천할 수 있으면 됩니다.
매일 고객에게 가치를 전달할 고민을 하고 협업을 하다 보면
자연스럽게 문제를 발견했을 때 빠르게 대처하고 또 업무를 진행할 수 있다고 생각합니다.
도메인, 유비쿼터스, 계층형 아키텍쳐, 집합 등 여러 생소한 개념들과 도메인 주도 설계가 무엇이고 필요한 이유를 이론적으로 배울 수 있어 좋았고 재밌게 읽었습니다.