도메인 주도 설계란 무엇인가? 1주차 - 김영명 #504
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 @ymkim97, 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 summarizes the first three chapters of the book 'Domain-Driven Design Quickly' by ymkim97. The summary covers key concepts like ubiquitous language, model-driven design, layered architecture, entities, value objects, services, modules, aggregates, factories, and repositories. It also includes Java code examples demonstrating the application of value objects and entities with Spring and JPA. Finally, the author raises some questions for discussion regarding layered architecture, the distinction between domain and application services, and criteria for extracting value objects from entities.
Highlights
- DDD Concepts: The pull request provides a summary of core DDD concepts discussed in chapters 1-3 of the book, including ubiquitous language, model-driven design, and various design patterns.
- Code Examples: Java code examples are included to illustrate the practical application of DDD concepts like Entities and Value Objects using Spring and JPA.
- Discussion Points: The author raises questions about layered architecture, service types, and value object extraction, inviting discussion and clarification.
Changelog
- 2025/Domain-Driven Design Quickly/ymkim97/chapter1_2_3.md
- Added a summary of chapters 1, 2, and 3 of 'Domain-Driven Design Quickly'.
- Included explanations of Ubiquitous Language, Model Driven Design, Layered Architecture, Entities, Value Objects, Services, Modules, Aggregates, Factories, and Repositories.
- Provided Java (Spring, JPA) code examples for Customer and Address entities.
- Raised discussion points regarding application layer logic, service types, and value object extraction criteria.
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 models reside,
DDD's principles, our faithful guide.
With language clear, and bounded context,
We build systems robust, no longer perplexed.
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
This pull request provides a summary of the book 'Domain-Driven Design Quickly' and discusses key concepts like ubiquitous language, model-driven design, and various patterns used in DDD. The author also raises some interesting discussion points about layered architecture, services, and value objects. Overall, it's a well-structured and informative summary.
Merge Readiness
The pull request is a well-written summary of the book and raises interesting discussion points. I don't see any critical or high severity issues that would block merging. Therefore, I recommend that the pull request is ready to be merged, but other reviewers should also review and approve this code before merging, as I am unable to approve it directly.
|
우측에 있는 |
ymkim97
requested review from
wooyaggo86,
jongfeel,
TaeHyoungKwon,
jintaeyeong,
hemil0102 and
tttghost
| 클라이언트는 모델에만 집중하도록 하고 객체의 저장이나 접근과 관련된 내용은 리파지토리에 위임한다. | ||
|
|
||
| ## [논의 내용] | ||
| * **3장 - 56 페이지**에서 레이어드 아키텍처의 애플리케이션 레이어에 대한 설명에서 “업무 로직을 포함하지 않는다.” 라고 적혀있습니다. 그런데 다음 페이지에서는 “애플리케이션 작업 전반을 조율하고 관리 비즈니스 로직이 그 안에 존재한다” 라고 적혀있습니다. 제가 이해하기로는 업무 로직이 곧 비즈니스 로직인데, 이는 해당 레이어에 있는게 자연스럽다고 생각해 왔어서 혼란스러웠습니다. 제가 잘못 이해하고 있었던 것인지, 내용이 잘못 적힌 것인지 논의해보고 싶습니다. |
There was a problem hiding this comment.
레이어드 아키텍처의 애플리케이션 레이어에 대한 설명에서 “업무 로직을 포함하지 않는다.”
이부분에서 설명하는 Application Layer는 퍼사드 역할을 하는 Application Service 에 대한 얘기를 하는 것으로 보입니다. 이 경우에 Application layer는 비즈니스 로직 구현의 책임을 가지기 보단, 도메인 객체, 도메인 서비스 객체, 리파지토리 객체 등 객체간에 상호작용을 조정하는 역할로 볼 수 있고 이 경우에 비즈니스 로직은 도메인 객체에 있어야하는게 맞습니다
그런데 다음 페이지에서는 “애플리케이션 작업 전반을 조율하고 관리 비즈니스 로직이 그 안에 존재한다” 라고 적혀있습니다.
이 문장 역시 위와 같은 맥락에서 이해할 수 있습니다 여기서 말하는 애플리케이션 레이어는 위 설명과 같이 여러 객체들 간의 작업을 조정하는 역할만 하고, 비즈니스 로직은 애플리케이션 레이어가 아닌, 도메인 객체가 가지고 있는 것이 맞습니다
제가 이해하기로는 업무 로직이 곧 비즈니스 로직인데, 이는 해당 레이어에 있는게 자연스럽다고 생각해 왔어서 혼란스러웠습니다. 제가 잘못 이해하고 있었던 것인지, 내용이 잘못 적힌 것인지 논의해보고 싶습니다.
흔히 자바 스프링 개발자들 기준으로 서비스 객체의 책임 무엇이냐고 물어볼 때, 많은 경우에 비즈니스 로직을 작성하는 것을 말하시는 분들을 많이 보았습니다 제가 생각했을 때, 이렇게 답하는 이유는 대개의 경우, 비즈니스로직 작성을 트랜잭션 스크립트 패턴 방식으로 작성하시는 분들이 서비스 객체의 메소드 하나에 비즈니스 로직을 모두 담아서 작성하는 코드를 주로 작성하기 떄문입니다
그러나, 이 책에서 말하는 애플리케이션 레이어 즉, 서비스 객체에 대한 설명은 트랜잭션 스크립트 패턴을 기준으로 설명하지 않고, 도메인 모델링으로 설계된 도메인 객체를 이용해서, 비즈니스로직을 작성한다는 전제하에 설명하고 있기 때문에, 여기서의 애플리케이션 레이어는 비즈니스 로직을 가지지 않고, 그 비즈니스 로직은 도메인 객체들이 가지고 있는 것 입니다
즉, 책이 틀린 것은 아니라고 생각하고, 애플리케이션 레이어(서비스 객체)에 대한 정의가 각 사람마다 이해하는 수준이다 범위가 다르기 때문에, 책을 읽으면서 혼란이 발생했다? 정도로 이해해 볼 수 있을 것 같습니다
There was a problem hiding this comment.
책에서는 애플리케이션 서비스와 도메인 서비스를 혼용한 것 같네요..
|
|
||
| ## [논의 내용] | ||
| * **3장 - 56 페이지**에서 레이어드 아키텍처의 애플리케이션 레이어에 대한 설명에서 “업무 로직을 포함하지 않는다.” 라고 적혀있습니다. 그런데 다음 페이지에서는 “애플리케이션 작업 전반을 조율하고 관리 비즈니스 로직이 그 안에 존재한다” 라고 적혀있습니다. 제가 이해하기로는 업무 로직이 곧 비즈니스 로직인데, 이는 해당 레이어에 있는게 자연스럽다고 생각해 왔어서 혼란스러웠습니다. 제가 잘못 이해하고 있었던 것인지, 내용이 잘못 적힌 것인지 논의해보고 싶습니다. | ||
| * 서비스에 관한 부분에서, 서비스는 애플리케이션 레이어나 도메인 레이어에 속할 수도 있다고 합니다. 그런데 저는 도메인 서비스와 애플리케이션 서비스의 차이를 어떻게 구분지어야 할지 고민입니다. 혹시 이에 대해 경험 혹은 해석이 있으신 분이 있으시다면 의견을 들어보고 싶습니다. |
There was a problem hiding this comment.
서비스를 크게 애플리케이션 서비스와 도메인 서비스로 나눈다고 할 때,
- 애플리케이션 서비스는 위에서 설명한 것처럼 여러 객체들을 조정 하는 퍼사드 역할
- 도메인 서비스는 각 도메인 객체의 책임으로 넣기 애매한 것들을 처리하기 위한 역할
로 볼 수 있을 것 같습니다
위에 대한 내용은 자바/스프링 개발자를 위한 실용주의 프로그래밍 책에 나온 내용을 첨부합니다
There was a problem hiding this comment.
저도 완벽하게 이해한 것은 아니지만 서로 다른 모듈로 분리했을 때, "동일 모듈 + 외부 도움(DB 조회 등) 없음"이라면 도메인 서비스일 확률이 높다고 이해했습니다.
| ## [논의 내용] | ||
| * **3장 - 56 페이지**에서 레이어드 아키텍처의 애플리케이션 레이어에 대한 설명에서 “업무 로직을 포함하지 않는다.” 라고 적혀있습니다. 그런데 다음 페이지에서는 “애플리케이션 작업 전반을 조율하고 관리 비즈니스 로직이 그 안에 존재한다” 라고 적혀있습니다. 제가 이해하기로는 업무 로직이 곧 비즈니스 로직인데, 이는 해당 레이어에 있는게 자연스럽다고 생각해 왔어서 혼란스러웠습니다. 제가 잘못 이해하고 있었던 것인지, 내용이 잘못 적힌 것인지 논의해보고 싶습니다. | ||
| * 서비스에 관한 부분에서, 서비스는 애플리케이션 레이어나 도메인 레이어에 속할 수도 있다고 합니다. 그런데 저는 도메인 서비스와 애플리케이션 서비스의 차이를 어떻게 구분지어야 할지 고민입니다. 혹시 이에 대해 경험 혹은 해석이 있으신 분이 있으시다면 의견을 들어보고 싶습니다. | ||
| * 엔티티의 특정 속성 값들을 “값 객체”로 빼내는 기준을 어떻게 잡는 것이 좋을지 궁금합니다. 물론 초기 설계부터 바로 값 객체로 빼내지는 않을 것 같은데 좀 더 구체적으로, 실제로 어떤 상황에서 값 객체로 빼내게 되는지 여러분의 경험과 기준을 들어보고 싶습니다. |
There was a problem hiding this comment.
일단 제 개인적으로는 값 객체 식별에 대해서는 상대적으로 덜 신경을 쓰는 편 입니다
그래서, 값객체를 어떻게 활용하고 식별해서 사용해야한다, 어느 시기에 활용해야한다 등의 기준은 없는거 같습니다
흔한 조언으로는 초기부터 값객체를 식별하기보다, 설계 -> 코드 작성 -> 유지보수 하는 과정에서 드러나는 맥락을 기준으로 빼내라가 있는 것 같습니다
There was a problem hiding this comment.
저도 이 부분에 대해서 많이 고민해봤는데, 의식적으로 계속 생각하는 것 밖에 답이 없는 것 같습니다.
처음부터 값 객체로 빼면 오히려 의미 없는 값 객체때문에 유지보수성을 해칠수도 있어서, 주의해야할 것 같습니다.
| 클라이언트는 모델에만 집중하도록 하고 객체의 저장이나 접근과 관련된 내용은 리파지토리에 위임한다. | ||
|
|
||
| ## [논의 내용] | ||
| * **3장 - 56 페이지**에서 레이어드 아키텍처의 애플리케이션 레이어에 대한 설명에서 “업무 로직을 포함하지 않는다.” 라고 적혀있습니다. 그런데 다음 페이지에서는 “애플리케이션 작업 전반을 조율하고 관리 비즈니스 로직이 그 안에 존재한다” 라고 적혀있습니다. 제가 이해하기로는 업무 로직이 곧 비즈니스 로직인데, 이는 해당 레이어에 있는게 자연스럽다고 생각해 왔어서 혼란스러웠습니다. 제가 잘못 이해하고 있었던 것인지, 내용이 잘못 적힌 것인지 논의해보고 싶습니다. |
There was a problem hiding this comment.
책에서는 애플리케이션 서비스와 도메인 서비스를 혼용한 것 같네요..
|
|
||
| ## [논의 내용] | ||
| * **3장 - 56 페이지**에서 레이어드 아키텍처의 애플리케이션 레이어에 대한 설명에서 “업무 로직을 포함하지 않는다.” 라고 적혀있습니다. 그런데 다음 페이지에서는 “애플리케이션 작업 전반을 조율하고 관리 비즈니스 로직이 그 안에 존재한다” 라고 적혀있습니다. 제가 이해하기로는 업무 로직이 곧 비즈니스 로직인데, 이는 해당 레이어에 있는게 자연스럽다고 생각해 왔어서 혼란스러웠습니다. 제가 잘못 이해하고 있었던 것인지, 내용이 잘못 적힌 것인지 논의해보고 싶습니다. | ||
| * 서비스에 관한 부분에서, 서비스는 애플리케이션 레이어나 도메인 레이어에 속할 수도 있다고 합니다. 그런데 저는 도메인 서비스와 애플리케이션 서비스의 차이를 어떻게 구분지어야 할지 고민입니다. 혹시 이에 대해 경험 혹은 해석이 있으신 분이 있으시다면 의견을 들어보고 싶습니다. |
There was a problem hiding this comment.
저도 완벽하게 이해한 것은 아니지만 서로 다른 모듈로 분리했을 때, "동일 모듈 + 외부 도움(DB 조회 등) 없음"이라면 도메인 서비스일 확률이 높다고 이해했습니다.
| ## [논의 내용] | ||
| * **3장 - 56 페이지**에서 레이어드 아키텍처의 애플리케이션 레이어에 대한 설명에서 “업무 로직을 포함하지 않는다.” 라고 적혀있습니다. 그런데 다음 페이지에서는 “애플리케이션 작업 전반을 조율하고 관리 비즈니스 로직이 그 안에 존재한다” 라고 적혀있습니다. 제가 이해하기로는 업무 로직이 곧 비즈니스 로직인데, 이는 해당 레이어에 있는게 자연스럽다고 생각해 왔어서 혼란스러웠습니다. 제가 잘못 이해하고 있었던 것인지, 내용이 잘못 적힌 것인지 논의해보고 싶습니다. | ||
| * 서비스에 관한 부분에서, 서비스는 애플리케이션 레이어나 도메인 레이어에 속할 수도 있다고 합니다. 그런데 저는 도메인 서비스와 애플리케이션 서비스의 차이를 어떻게 구분지어야 할지 고민입니다. 혹시 이에 대해 경험 혹은 해석이 있으신 분이 있으시다면 의견을 들어보고 싶습니다. | ||
| * 엔티티의 특정 속성 값들을 “값 객체”로 빼내는 기준을 어떻게 잡는 것이 좋을지 궁금합니다. 물론 초기 설계부터 바로 값 객체로 빼내지는 않을 것 같은데 좀 더 구체적으로, 실제로 어떤 상황에서 값 객체로 빼내게 되는지 여러분의 경험과 기준을 들어보고 싶습니다. |
There was a problem hiding this comment.
저도 이 부분에 대해서 많이 고민해봤는데, 의식적으로 계속 생각하는 것 밖에 답이 없는 것 같습니다.
처음부터 값 객체로 빼면 오히려 의미 없는 값 객체때문에 유지보수성을 해칠수도 있어서, 주의해야할 것 같습니다.
|
|
||
| 지금까지는 DDD에 대해 아주 어렴풋이 알고 있어서, 이번 기회를 통해 좀 더 개념을 잡아갈 수 있을 것 같아 읽기 전부터 기대가 되었고, 정말 재밌게 읽었습니다. 에릭 에반스의 책 “Domain-Driven Design”을 정리하고 요약한 버전인 비교적 가벼운 책이기 때문에, 에반스의 책을 읽기 전에 읽기 딱 좋은 것 같습니다. 따라서 이 책을 다 읽고 에반스의 책을 읽어 보기로 마음을 가지게 되었습니다. | ||
|
|
||
| 책에서 등장하는 개념들은 그 자체로 70% ~ 80%는 이해가 되는 것 같지만, 실제 코드로 구현하기 위해서는 어떻게 해야하는지 잘 그려지지 않았습니다. 호기심을 해결하고 나머지 20% ~ 30%의 이해를 채우기 위해서 “도메인 주도 개발 시작하기” 책도 구매하였고, 이 또한 읽을 예정입니다. |
There was a problem hiding this comment.
완벽하게 정독하려고 했지만 생각보다 개념이해가 어렵더라구요 저는 40%정도 이해한 듯 합니다.
다시한번 봐야겠습니다.
| ## [논의 내용] | ||
| * **3장 - 56 페이지**에서 레이어드 아키텍처의 애플리케이션 레이어에 대한 설명에서 “업무 로직을 포함하지 않는다.” 라고 적혀있습니다. 그런데 다음 페이지에서는 “애플리케이션 작업 전반을 조율하고 관리 비즈니스 로직이 그 안에 존재한다” 라고 적혀있습니다. 제가 이해하기로는 업무 로직이 곧 비즈니스 로직인데, 이는 해당 레이어에 있는게 자연스럽다고 생각해 왔어서 혼란스러웠습니다. 제가 잘못 이해하고 있었던 것인지, 내용이 잘못 적힌 것인지 논의해보고 싶습니다. | ||
| * 서비스에 관한 부분에서, 서비스는 애플리케이션 레이어나 도메인 레이어에 속할 수도 있다고 합니다. 그런데 저는 도메인 서비스와 애플리케이션 서비스의 차이를 어떻게 구분지어야 할지 고민입니다. 혹시 이에 대해 경험 혹은 해석이 있으신 분이 있으시다면 의견을 들어보고 싶습니다. | ||
| * 엔티티의 특정 속성 값들을 “값 객체”로 빼내는 기준을 어떻게 잡는 것이 좋을지 궁금합니다. 물론 초기 설계부터 바로 값 객체로 빼내지는 않을 것 같은데 좀 더 구체적으로, 실제로 어떤 상황에서 값 객체로 빼내게 되는지 여러분의 경험과 기준을 들어보고 싶습니다. |
There was a problem hiding this comment.
저는 값을 복사한 객체가 필요한데 불변이어야 하는 때가 있으면 추가로 설계해서 쓰곤 합니다.
C# 은 과거에 구조체를 주로 썼는데 record 라는 게 생겨서 record struct 로 선언하면 딱 도메인 주도 설계에서 얘기하는 값 객체에 부합하는 객체를 만들 수 있습니다.
|
|
||
| ## [논의 내용] | ||
| * **3장 - 56 페이지**에서 레이어드 아키텍처의 애플리케이션 레이어에 대한 설명에서 “업무 로직을 포함하지 않는다.” 라고 적혀있습니다. 그런데 다음 페이지에서는 “애플리케이션 작업 전반을 조율하고 관리 비즈니스 로직이 그 안에 존재한다” 라고 적혀있습니다. 제가 이해하기로는 업무 로직이 곧 비즈니스 로직인데, 이는 해당 레이어에 있는게 자연스럽다고 생각해 왔어서 혼란스러웠습니다. 제가 잘못 이해하고 있었던 것인지, 내용이 잘못 적힌 것인지 논의해보고 싶습니다. | ||
| * 서비스에 관한 부분에서, 서비스는 애플리케이션 레이어나 도메인 레이어에 속할 수도 있다고 합니다. 그런데 저는 도메인 서비스와 애플리케이션 서비스의 차이를 어떻게 구분지어야 할지 고민입니다. 혹시 이에 대해 경험 혹은 해석이 있으신 분이 있으시다면 의견을 들어보고 싶습니다. |
There was a problem hiding this comment.
서비스의 본질은 변하지 않고 어느 레이어에 속해 있느냐에 차이만 있을 거라고 생각합니다.
도메인 주도 설계란 무엇인가? Chapter 1, 2, 3
최근에 들어서 관심을 가지게 되면서 공부해보고 싶었는데 때마침 시작하기 좋은 책인 것 같습니다.
그래서인지 정말 재밌게 읽었고, 더 나아가서 다른 DDD 관련 책들도 읽기로 했습니다.
뭔가 이야기를 나누고 싶고, 머리속에는 깨달으면서 배운 것이 많은데 이것들을 전부 정리하거나 전달하기가 쉽지 않네요.
그래도 최대한 미팅에서 꺼내보도록 해보겠습니다 ㅎㅎ