🥬 상추

🍝 짜왕

1. @Transactional의 readOnly모드 내부 동작 원리 공부하기

2. 도메인의 Id에 @Setter 써야하나? → @Setter를 써야지 DB의 자동 증가 id가 저장되는 줄 알았는데, 그게 아니었다. 바로 @Setter를 삭제하고 final로 변경.

   → 짜왕 : Issue, Label @Setter 삭제, 상추 : 짜왕꺼 외 @Setter 삭제

3. Controller, Service 계층별 역할을 생각해보고 'URI 주소를 만드는' 작업이 Controller에 들어가는 것이 맞는가?

4. MysqlDataTruncation -> 이름 길이 넘치는 오류 처리하기 → 나중에 DTO에 검증 추가하기

5. dto 변환 로직을 Mapper 클래스를 만들어 utils에 따로 구현하기

   → 상추 : IssueDetailService, 짜왕 : IssueFilterService

6. 라벨 텍스트 컬러도 배경색깔과 같이 검증을 해야할지? → 일단 보류

7. utils @Component 달기

8. domain → entity로 변경

9. 기본적으로 값을 재정의 해주지 않은 Object type의 equals의 동작이 있을텐데 Object type인 String은 왜 따로 재정의하지 않았는데도 왜 값을 비교하는지?

10. 존재하지 않는 id에 대한 핸들링 위치 → Repo에서 NotFoundException을 throw하는 것으로 변경

    • Repository를 래핑해서 id 기준으로 데이터가 존재하는지 여부 등에 대한 관심사를 위임하고 서비스에서는 한층 추상화된 형태로 순수하게 'Id 기준으로 마일스톤을 오픈하는' 것에만 집중할 수 있다.

11. 트랜잭션 격리 레벨에 따른 예상 동작들

    • @Transactional 기능과 엮어 볼 수 있습니다
    • 지금 어떤 DB를 사용하고 그때 서비스에서 적용되는@Transactional레벨이 어떤지?
    • 이 격리레벨에서 동시에 다른 요청이 같은 id의 데이터에 접근했을 때 해당 로직이 어떤 식으로 동작할지

🏃🏻 본