헌혈매칭(글) 엔티티 및 도메인 로직, API 구현 #23
Conversation
- 연관관계가 있는 반려동물, 동물병원 엔티티가 현재 존재하지 않아 id값으로 임시 작성
- 프로토타입 개발이 목표이기 때문에 어느 정도의 결합도를 허용하여 구현 - 추후 DIP, facade 패턴 등을 적용하여 레이어간 결합도를 최소화하도록 리팩토링할 예정 - ex) Controller -> Facade -> Service <- ServiceImpl - ex) ServiceImpl -> Reader <- ReaderImpl -> Repository
resolve: #22
|
nested class로 관련 있는 dto들을 묶은 거 되게 좋은 것 같습니다! |
|
저는 facade 패턴을
크게 위 두 가지의 이유로써 적용하고자 하는데, 한 개의 메서드만 필요하다면 전자의 경우는 필요가 없어지니, 후자의 경우 Interface를 사용하는 것만으로도 얻을 수 있다고 생각해서 사용하지 않아도 좋다고 생각합니다! 그리고 facade 패턴이 layered architecture, ddd의 application layer의 역할과 비슷하다고 생각하여 ddd로 개발하면서 한번 적용해 보고자 하는 생각도 있었습니다! ex) 간단한 facade 패턴 |
| private final LocalDateTime pullDate; | ||
| private final int pullCount; | ||
|
|
||
| public InfoResponse(BloodPost bloodPost) { |
There was a problem hiding this comment.
ObjectMapper 를 이용하는 방법은 어떻게 생각하시나요!?
똑같은 필드를 모두 가져오는 것 같아서요!!
There was a problem hiding this comment.
좋습니다~~
클라이언트 측에서 가공된 데이터를 필요로 하는 경우가 있을 것 같아 사용하지 않았는데, 우선적으로 ObjectMapper를 사용해도 좋을 것 같습니다!
| } | ||
|
|
||
| @Builder | ||
| public BloodPost( |
There was a problem hiding this comment.
별건 아니지만.. 기본값 설정하는 부분은 Property 에 직접
private Status status = Status.TODO
이런식으로 초기화하는 방식도 자주 사용하는것 같아요!!
There was a problem hiding this comment.
아하 그렇군요!!
이 부분은 추후에 다른 Status를 가진 생성자 혹은 정적 팩터리 메서드가 생기는 것을 고려하여 작성하였는데, 말씀해주신 방법도 좋을 것 같습니다!!
There was a problem hiding this comment.
조금 더 부연 설명을 해보자면, 새로운 객체의 생성 방법을 정의하는 경우(ex status가 DONE인 객체) 변수의 초기화가 되어있지 않으면 status가 null로 떨어져 값 세팅을 누락하는 실수를 방지할 수 있는 반면(nullable=false), 변수의 초기화가 되어있는 경우 status 값이 잘못 세팅되어 있는 것을 모르는 채로 넘어가 비즈니스에 문제가 생기는 경우가 발생할 수도 있을 거라는 생각을 했습니다!!
There was a problem hiding this comment.
그런 케이스가 있을 수 있겠네요! 말씀해주신 부분은 처음 Entity 가 생성될 때 다양한 값들이 들어가면서 생성되는 케이스일 것 같네요!
제가 말씀드린 전제는 Entity 가 생성될 때 기본값이 채워지는 상황이라면 위와같이 초기화 해도 괜찮을 것이라고 생각해서 말씀드린�것입니다 :D
|
말씀해주신 Facade 패턴은 DDD 의 Domain Service 개념과 매우 흡사하네요! |
|
넵 맞습니다! 말씀해주신 DDD의 도메인 서비스 역할을 생각했습니닷 |
|
|
||
| @Transactional | ||
| public BloodPostDto.ExpireResponse expireBloodPost(Long bloodPostId) { | ||
| BloodPost bloodPost = getBloodPost(bloodPostId); |
There was a problem hiding this comment.
나중에 변경되지 않을 변수는 final 키워드를 추가하면 더 좋을 것 같아요!
| public static class RegisterRequest { | ||
| @NotNull | ||
| private Long petId; |
There was a problem hiding this comment.
보통 inner 클래스는 맨 첫 줄과 끝 줄에 빈 줄을 추가하지 않는 걸까요?-?
There was a problem hiding this comment.
음... 일반 class convention과 동일하게 사용해도 좋을 것 같습니다! 저희가 약속해서 사용하면 될 것 같은데, 어떻게 할까요?
| ) { | ||
| List<BloodPostDto.InfoResponse> response = bloodPostService.selectAllBloodPost(status, title); | ||
|
|
||
| return ResponseEntity.ok(ResultResponse.of(ResultCode.BLOODPOST_SELECTALL_SUCCESS, response)); |
There was a problem hiding this comment.
ResultCode, ErrorCode는 static import해서 사용하는 건 어떨까요?!
There was a problem hiding this comment.
좋습니다~~ static import로 통일해서 사용하면 코드가 더 깔끔해지겠네요!
📌 Linked Issues
🔎 Change Details
헌혈 요청글 엔티티 및 도메인 로직 작성
끌어올리기 기능을 위해 pull_date, pull_count 컬럼을 추가하고 erd cloud에도 반영
연관관계가 있는 반려동물, 동물병원 엔티티가 현재 존재하지 않아 id값으로 임시 작성
헌혈 요청글 API 구현
동적 where절이 필요한 리스트 조회의 경우 spring data jpa의 query method를 사용하게 되면 메서드 이름이 너무 길어져 가독성이 떨어지고, 조건이 많아지는 만큼 많은 메서드를 만들어야 하는 단점이 있기 때문에, querydsl과 BooleanExpression을 사용하여 구현
💬 Comment
📑 References
✅ Check Lists