Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add chapter 1, 2, 3 review link and discussion #500

Merged
merged 1 commit into from
Mar 24, 2025
Merged

Add chapter 1, 2, 3 review link and discussion #500

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions 2025/Domain-Driven Design Quickly/jongfeel/Chapter1_2_3.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
## 책 내용 정리

1장 도메인 주도 설계란 무엇인가?

- https://github.com/jongfeel/BookReview/issues/1150

2장 유비쿼터스 언어

- https://github.com/jongfeel/BookReview/issues/1155

3장 모델 주도 설계

- https://github.com/jongfeel/BookReview/issues/1165

## 논의 주제

확실히 원래 책인 도메인 주도 설계 책에 비해 상당히 내용이 잘 압축되어 있고 챕터별로 주제 설명을 잘 해 둔 느낌이 있습니다.

실제 회사에서 개발 일 할때 도메인 주도 설계 방법으로 해 본 분은 없을거라 생각하는데
3장에서 설명하는 모델 주도 설계의 핵심적인 내용 중에 프레임워크나 라이브러리에서 지원하는 방식 말고
도메인 주도 설계를 알기 전에 비슷한 개념을 썼던 적이 있는지 얘기해 보면 어떨까 싶습니다.

저는 리파지토리는 이전에 웹 프론트엔드 할 때 썼던 개념인 스토어(Store)에 변화를 줘서 썼었고
서비스의 경우는 개념 그대로 가져와서 사용했습니다.

만약 개발 경험이 많이 없거나 실무 경험이 없으신 분들은
자신이 썼던 개발 환경에서 3장에서 얘기하는 개념들을 봤거나 쓴 경험에 대해 얘기해 봐도 좋을 것 같습니다.
Comment on lines +15 to +27
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저는 repository와 service를 주로 많이 활용했던 것 같습니다

but, 책에서 말하고 있는 엄밀한 의미에서 활용 했다기 보다는 repository는 DB 테이블당 1개씩 존재하는 DAO의 역할. 즉, 테이블 데이터 게이트웨이의 용도로 사용하면서, 이름만 repository 였고,

service 역시, 트랜잭션스크립트 패턴으로 작성된 절차지향 코드 뭉치들 혹은 그 뭉치들을 하위함수나 클래스로 추출한 것을 대략 service 라는 이름을 붙여서 사용했었습니다

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

집합 개념을 제외한 다른 개념들은 제가 개발을 처음 배울 때 부터 사용했었던 것 같습니다.
아무래도 스프링이 주로 ORM기술로 대규모 엔터프라이즈 시스템을 구축하는데 사용되기 때문이 아닐까 생각해봅니다..

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

팩토리 방식으로 다른 사람이 만들어 놓은 것을 사용한 경험이 있습니다. 이 팩토리가 왜 필요한지에 대해서는 명확히 인지를 못했었는데 이번 기회에 복잡한 객체 생성의 절차를 캡슐화하는 목적으로 사용한다는 것을 알게 되었습니다.

Comment on lines +15 to +27
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

만약 개발 경험이 많이 없거나 실무 경험이 없으신 분들은 자신이 썼던 개발 환경에서 3장에서 얘기하는 개념들을 봤거나 쓴 경험에 대해 얘기해 봐도 좋을 것 같습니다.

저도 비슷하게 흉내만 냈던 내용들이 좀 더 명확하게 개념이 잡혀서 좋았습니다. 특히 서비스부분이 가장 좋았던 것 같습니다 항상 위쪽에 더 큰 개념으로 객체에 대한 책임 부분이 강했는데 서비스라는 좋은 답을 얻은 것 같아서..