-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
회원의 대출 목록 조회 추가 #12
회원의 대출 목록 조회 추가 #12
Conversation
@Override | ||
public List<BorrowDetails> findBorrows(long memberId) { | ||
return borrowService.findBorrows(memberId); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DDD 에서 보통 Query 와 Command 는 Service 레벨부터 분리합니다.
쿼리 책임과 커맨드 책임 자체를 분리하기 때문인데요. 한번 관련한 내용들을 찾아보고 리팩토링 해보세요
public class BorrowDetails { | ||
private long id; // 대출 ID | ||
private Member member; // 회원 | ||
private Book book; // 도서 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Member
나 Book
객체는 도메인 객체죠?
쿼리 객체라면 도메인 객체 대신 쿼리 모델에 맞는 구성 객체들을 사용하는 방식이 될 것입니다.
- 레이어에서 command와 query로 분리 - 쿼리 객체에 맞는 구성 객체 추가 (MemberView, BookView)
command, query가 같은 DB를 사용할 경우, 인프라 레이어의 Entity는 command, query 공용으로 사용해도 무방한지 궁금합니다. |
그럼요 ㅎㅎ 무방합니다. 물론 조회 조건은 워낙 디비 친화적인 조건이 많아서 조회에 대한 요구조건이 늘 수록 같이 쓰기 어려워지긴 하지만요 |
도서와 회원 객체에 대한 대출 목록 조회 시 쿼리 객체(BorrowDetails)로 응답