Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @hemil0102, 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 a markdown document reflecting on the first week of reading the book 'Domain-Driven Design Quickly'. The author, hemil0102, shares their thoughts on the book's content, particularly focusing on the challenges of understanding the concepts without code examples in chapter 3. They also draw parallels between Domain-Driven Design (DDD) and Clean Architecture, and pose questions about the similarities and differences between the two architectural styles.
Highlights
- Reflections on DDD: The author reflects on the core concepts of DDD, such as the importance of understanding the real world, ubiquitous language, and model-driven design.
- DDD vs Clean Architecture: The author explores the similarities and differences between DDD and Clean Architecture, noting that both aim to solve real-world problems and share similar concepts.
- Challenges in Understanding DDD: The author mentions the initial difficulty in grasping DDD concepts without code examples and how GPT helped in understanding the context.
Changelog
- 2025/Domain-Driven Design Quickly/hemil0102/1장.md
- Initial commit of the markdown document containing reflections on the first week of reading 'Domain-Driven Design Quickly'.
- The document includes thoughts on the book's content, challenges in understanding DDD concepts, and a comparison between DDD and Clean Architecture.
- It also poses questions about the similarities and differences between the two architectural styles.
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 realms of code, where domains reside,
DDD's wisdom, a guiding tide.
Models emerge, with language clear,
Solving problems, banishing fear.
Though architectures may intertwine,
DDD's essence, a design divine.
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 reflection on the book 'Domain-Driven Design Quickly,' focusing on the challenges and insights gained from understanding DDD concepts. The author shares their experiences with applying GPT to generate code examples and discusses the similarities and differences between DDD and Clean Architecture. Overall, it's a thoughtful reflection on the book's content and its practical implications.
Merge Readiness
The pull request consists of a markdown file reflecting on the book 'Domain-Driven Design Quickly'. There are no specific code changes to assess for correctness, efficiency, or security. The content is a personal reflection and doesn't require strict technical review. Therefore, I would recommend that other reviewers read through the markdown file and ensure that it is consistent with the project's goals. I am unable to directly approve the pull request, and that users should have others review and approve this code before merging.
hemil0102
requested review from
jongfeel,
TaeHyoungKwon,
jintaeyeong,
ymkim97,
fkdl0048,
dhlee3994 and
tttghost
| 1. 클린 아키텍처나 DDD나 현실 세계의 어떤 문제를 해결하거나 개선한다는 점에서 두 아키텍처는 닮아 있다고도 생각하는데... 둘 다 도메인 영역이 존재하고 레퍼지토리도 있고, 부분 부분 영역이 다를 뿐 ... 저장소에서 데이터를 끌어와서 로직에서 처리하고 외곽 사용자에게 UI를 통해 표현되는 점은 또는 그 반대의 흐름은 큰 맥락에서 같아보입니다. | ||
|
|
||
| 두 아키텍처의 큰 차이점과 공통점은 뭐라고 생각하시나요? | ||
| 클린 아키텍처 개발자가 했던 말 중에 결국에 30년을 소프트웨어 개발을 했는데 마지막에 내가 사용하는 아키텍처는 비슷비슷했어 그게 클린 아키텍처야 라는 말을 했는데, 동의하시나요? |
There was a problem hiding this comment.
우선 저는 클린 아키텍쳐에 대해서 잘 모르기 때문에, 차이점과 공통점에 대해서 확실하게 단정지어서, 말을 할 순 없을것 같네요
하지만, 한가지 확실하게 말할 수 있는 것은 DDD와 클린아키텍쳐는 서로 비교대상이 아니며, DDD가 클린 아키텍쳐보다 훨씬 더 큰 범위를 다룬다는 점 입니다
클린아키텍쳐는 제가 아는 수준에선, 코드 레벨에서의 아키텍쳐 구조를 어떻게 유연하게 설계할 것인가에 초점이 맞춰져 있습니다. 코드레벨에서 설계와 구현에 치중 되어있다고 볼 수 있을 것 같습니다
반면에, DDD는 복잡한 도메인을 가진 소프트웨어를 어떻게 다양한 직군의 사람들과 협력해서 설계 할 것이고(도메인 모델링), 이 결과물로 나온 도메인 모델을 기준으로 도메인 객체들 간에 협력과 경계 설정 등 할것인지(전략적 설계), 이 전략적 설계를 바탕으로, 실제적인 구현을 어떻게 할 것인지(전술적 설계) 까지를 아우른 것으로 볼 수 있을 것 같습니다
클린아키텍쳐에도 레이어를 나누고, 엔티티, 서비스 리파지토리가 존재하고, DDD에도 똑같이 존재하기 때문에 비슷한 아키텍쳐라고 느끼셨다면, DDD의 구체적인 구현을 어떻게 할 것인지에 대한 전술적 설계에만 해당되는 내용일 것으로 보입니다
관련해서는 아래 글을 보시면 이해에 도움이 될 것 같습니다
There was a problem hiding this comment.
클린 아키텍처 개발자가 했던 말 중에 결국에 30년을 소프트웨어 개발을 했는데 마지막에 내가 사용하는 아키텍처는 비슷비슷했어 그게 클린 아키텍처야 라는 말을 했는데, 동의하시나요?
글의 출처가 어떻게 되나요? (클린아키텍쳐 책을 봤는데도 어디서 나온말인지 모르겠네요) 말씀주신 부분만 봐서는 문맥을 정확히 알 수가 없을 것 같습니다
There was a problem hiding this comment.
클린 아키텍처나 DDD나 현실 세계의 어떤 문제를 해결하거나 개선한다는 점에서 두 아키텍처는 닮아 있다고도 생각하는데
소프트웨어 자체가 현실 세계의 문제를 해결하기 위함이니 그 어떤 이론이 와도 똑같을 것 같습니다.
그리고 제가 알기로는 클린 아키텍처는 저자가 제시하는 여러 원칙을 지키면 어떤 형태던 상관없는 것으로 알고있습니다.
There was a problem hiding this comment.
클린 아키텍처 개발자가 했던 말 중에 결국에 30년을 소프트웨어 개발을 했는데 마지막에 내가 사용하는 아키텍처는 비슷비슷했어 그게 클린 아키텍처야 라는 말을 했는데, 동의하시나요?
글의 출처가 어떻게 되나요? (클린아키텍쳐 책을 봤는데도 어디서 나온말인지 모르겠네요) 말씀주신 부분만 봐서는 문맥을 정확히 알 수가 없을 것 같습니다
음 제 기억에는 출처가 클린 아키텍처 책 서두였던 걸로 기억해요. 저자가 클린 아키텍처를 소개하면서 게임 개발도 하고 여러 소프트웨어 개발도 해보고 하니 궁극적으로 클린 아키텍처와 비슷한 형태로 아키텍처를 계속 사용하게 되더라~ 라고 봤었는데 지금은 책이 없어서 확인 불가입니다.
There was a problem hiding this comment.
클린 아키텍처나 DDD나 현실 세계의 어떤 문제를 해결하거나 개선한다는 점에서 두 아키텍처는 닮아 있다고도 생각하는데
소프트웨어 자체가 현실 세계의 문제를 해결하기 위함이니 그 어떤 이론이 와도 똑같을 것 같습니다. 그리고 제가 알기로는 클린 아키텍처는 저자가 제시하는 여러 원칙을 지키면 어떤 형태던 상관없는 것으로 알고있습니다.
네 뭔가 아키텍처가 비슷한데, DDD는 단지 아키텍처라기 보다는 조금 더 포괄적으로 소프트웨어 개발 방법론?을 말하는 것 같아요.
There was a problem hiding this comment.
제가 클린 아키텍처 책이 있기 때문에 찾아보고 알려드리면 다음 내용을 잘못 생각해서 해석하신게 아닌가 싶네요.
내 인생 첫 줄의 코드를 작성한 게 1964년 ... 지금은 2016년이 되었으니, 무려 반세기 이상 코드를 작성한 셈이다.
...
나는 수많은 앱을 만들었다. 수많은 시스템을 구축했다. 그리고 이 모두를 경험하고 고민한 끝에 놀라운 무언가를 깨달았다.
아키텍처 규칙은 동일하다!
30년(X) -> 반세기(O)
클린 아키텍처였다 (X) -> 아키텍처 규칙은 동일하다! (O)
There was a problem hiding this comment.
제가 클린 아키텍처 책이 있기 때문에 찾아보고 알려드리면 다음 내용을 잘못 생각해서 해석하신게 아닌가 싶네요.
내 인생 첫 줄의 코드를 작성한 게 1964년 ... 지금은 2016년이 되었으니, 무려 반세기 이상 코드를 작성한 셈이다.
...
나는 수많은 앱을 만들었다. 수많은 시스템을 구축했다. 그리고 이 모두를 경험하고 고민한 끝에 놀라운 무언가를 깨달았다.
아키텍처 규칙은 동일하다!30년(X) -> 반세기(O) 클린 아키텍처였다 (X) -> 아키텍처 규칙은 동일하다! (O)
오호 맞습니다. 이런 맥락이었는데 기억이 많이 바뀌어있네요 ㅋ.ㅋ
아키텍처 규칙은 동일한데 이러이러하다로 본게 맞아요.
그래서 아 아키텍처들은 종국엔 비슷한건가... 이런 생각을 했던 것 같습니다.
| 1. 클린 아키텍처나 DDD나 현실 세계의 어떤 문제를 해결하거나 개선한다는 점에서 두 아키텍처는 닮아 있다고도 생각하는데... 둘 다 도메인 영역이 존재하고 레퍼지토리도 있고, 부분 부분 영역이 다를 뿐 ... 저장소에서 데이터를 끌어와서 로직에서 처리하고 외곽 사용자에게 UI를 통해 표현되는 점은 또는 그 반대의 흐름은 큰 맥락에서 같아보입니다. | ||
|
|
||
| 두 아키텍처의 큰 차이점과 공통점은 뭐라고 생각하시나요? | ||
| 클린 아키텍처 개발자가 했던 말 중에 결국에 30년을 소프트웨어 개발을 했는데 마지막에 내가 사용하는 아키텍처는 비슷비슷했어 그게 클린 아키텍처야 라는 말을 했는데, 동의하시나요? |
There was a problem hiding this comment.
클린 아키텍처나 DDD나 현실 세계의 어떤 문제를 해결하거나 개선한다는 점에서 두 아키텍처는 닮아 있다고도 생각하는데
소프트웨어 자체가 현실 세계의 문제를 해결하기 위함이니 그 어떤 이론이 와도 똑같을 것 같습니다.
그리고 제가 알기로는 클린 아키텍처는 저자가 제시하는 여러 원칙을 지키면 어떤 형태던 상관없는 것으로 알고있습니다.
| 이런 부분이 책에서 말하는 내용과 일치해서 공감을 많이 했다. | ||
|
|
||
| ### 1장 도메인 주도 설계란 무엇인가? | ||
| 현실 세계의 무언가를 소프트웨어로 구현하기 위해 필수 개념들을 도출하는 것 |
There was a problem hiding this comment.
이책을 접할수 있어서 좋았던 점은
어렴풋이 이러한 개념이 있을것 같다고 생각했는데
그게 도메인 주도 설계더군요.
| ### 논제 | ||
| 1. 클린 아키텍처나 DDD나 현실 세계의 어떤 문제를 해결하거나 개선한다는 점에서 두 아키텍처는 닮아 있다고도 생각하는데... 둘 다 도메인 영역이 존재하고 레퍼지토리도 있고, 부분 부분 영역이 다를 뿐 ... 저장소에서 데이터를 끌어와서 로직에서 처리하고 외곽 사용자에게 UI를 통해 표현되는 점은 또는 그 반대의 흐름은 큰 맥락에서 같아보입니다. | ||
|
|
||
| 두 아키텍처의 큰 차이점과 공통점은 뭐라고 생각하시나요? | ||
| 클린 아키텍처 개발자가 했던 말 중에 결국에 30년을 소프트웨어 개발을 했는데 마지막에 내가 사용하는 아키텍처는 비슷비슷했어 그게 클린 아키텍처야 라는 말을 했는데, 동의하시나요? |
There was a problem hiding this comment.
저는 뭔가 방법론 + 설계 방법에 가깝다는 생각이 들었습니다. 클린 아키텍처는 설계 방법이라면 DDD는 결국 "설계에는 소통이 빠지면 안되더라"를 말하고 싶어한다는 생각이 들었습니다.
지난 책과 달리 조금 가볍게 읽을 수 있어 좋다가도...
3장에서 코드 없이 개념적인 이론을 읽으려니 힘들었습니다.
확실히 초급자 입장에서는 책만 보고 이해하기엔 버거운게 맞긴 한게
오퍼레이션의 의미 불변식이란 용어 등등을 자연스럽게 누구나 다 아는 것 처럼 기술한 것으로 읽기가 힘들었습니다.
그나마 GPT의 도움을 통해 코드를 작성하면서 각각의 용어가 무엇을 의미하는지 알아갔던 것 같습니다.
책의 흐름은 1, 2장의 현실 세계 문제에 초점을 맞춰서 도메인 모델을 설계한 것에 반해
3장에서 갑자기 아키텍처적인 개발자 느낌으로 분위기가 변해서...
그럼 도메인 주도라서 더 특별한 점은 무엇인가? 현실 세계는 어디갔어?
뭔가 잘 설명되고 있는건가라는 느낌이 들다가,
소프트웨어 품질적인 면으로 설명이 유익해보여서 이해하려는 노력을 했습니다.
이 밖에 개발자가 아닌 다른 이해관계자가 DDD를 어떻게 생각하고 모델 설계하는지,
이런 설계 방식을 중요하게 생각하는지,
보통은 개발자가 알아서 하는 경우가 더 많았던 것 같아서,
비개발자의 이야기도 들어보고 싶네요.