1. 패키지 구조
패키지 구조의 개선이 필요할 것 같아요.
- 지금 같은 depth에 domain 관련과 config, error 등이 섞여있는데 필요한 도메인을 찾기가 불편한 구조인 것 같습니다..!!
- 그리고 도메인 안에서도 뭔가 애매하게 나눠진 기분이여서 조금 더 개선해보면 좋을 것 같아요~
패키지 구조 관련해서 이전에 참고했던 링크입니다.
![[스터디] 도메인 주도 설계 4주차 (1부 끝)](https://www.notion.so/image/https%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fstatic%2Ficon%2Ffavicon%2Ffavicon64_150520.ico?table=block&id=432403b9-889a-4261-b127-99bde8e240a6&cache=v2)
![[스터디] 도메인 주도 설계 4주차 (1부 끝)](https://www.notion.so/image/http%3A%2F%2Fimg1.daumcdn.net%2Fthumb%2FR1280x0.fjpg%2F%3Ffname%3Dhttp%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2F2MrI%2Fimage%2FlBecb82AHBANfzvhbmvMC3PkPfU.jpeg?table=block&id=432403b9-889a-4261-b127-99bde8e240a6&cache=v2)
2. Entity와 DTO
Entity와 DTO 검증 할 때 어떻게 하는 것이 일관성(?)을 유지하는데 좋을까요?
- 예를 들어서 앨범에서 제목은 20자 이내만 들어갈 수 있는데, DTO 생성 시 똑같이 20자 이내로 입력되도록 검증해야 하는데 이렇게 할 경우 실수할 가능성도 있기 때문에 숫자를 그냥 쓰는게 맘에 안들어요... 그냥 VO에서 한 번만 검증 하나요..? 여러가지 방법이 있을 것 같은데 어떤 방식이 가장 좋을까요? (아래는 그냥 예시)
- 그리고 message 부분 ResponseMessage로 관리해도 되나요?
- Entity
- DTO
3. DTO Inner class
롬복을 사용하지 않아서 코드가 길어지는데 Inner class로 관리하는게 맞는 걸까요?
- 롬복을 사용할 경우에 getter, builder 어노테이션만 달면 끝나던 코드가 직접 getter 구현하고 builder 구현하다보면 엄청 길어지더라고요.
- 이렇게 코드가 길어지는데 Inner class로 관리하는게 맞나라는 생각이 들어요.
- Inner class로 관리했을 때의 장점이 사라지는 기분
4. Bundle
구피 Bundle 설명 다시 해주세요!!
- Bundle 관련 너무 초반에 들어서 기억이 잘 안나네요. 구피 레포 코드 보면서 왜 사용하는지 대충 이해는 했는데, 실제로 API 짜다보면 bundle이 필요 없거나 사용하기 애매한 경우도 있어서 설명 다시 듣고 싶습니다!
- 검색 해보려고 했는데 뭐라고 쳐야 할지,, 원하는 자료가 안나오더라고요.
5. Response
생성 or 수정 후 응답 보낼 때 createdAt, modifiedAt 도 같이 보내나요?
- 구피, 데비는 어떻게 하고 있나요?
- 전체적으로 네이밍이 이상함.
- API request에 대한 로깅 필요.
- facade와 service의 역할 분명히 하기
- 글로벌 예외 처리 추가적으로 필요함
- response enum에 있는 한글 메세지는 어디에 사용되나?
- patch 안 쓰는 이유? 왜 put인가
- update는 칼럼 하나에 대해서 도메인에 메소드 만들 것인지?
- response 구조 개선
- 현재 : ResponseEntity<RespontDto<CreateAlbumResponse>>>