아직 DDD에 대한 지식이 너무너무 부족해서 설명할 순 없지만 미래의 MSA로 변환한다고 가정했을 때 쉽게 바꿀 수 있다고 생각하여 도메인 별로 패키지를 나눴다.Service 쪽에선 Port 패키지에 존재하는 Repository만 의존하고 있으며 JPA를 사용하고 있지
📖 JPA 벌크성 Update 주문 취소 로직중 벌크성 업데이트를 고려하지 않고 특정 주문에 대한 주문 상세들을 모두 가져와서 반복문으로 바꿔주었었다. 코드를 보자! 이렇게 코드를 작성하게 되면
@Transactional를 통해 각 테스트가 롤백되어 productId가 모두 1L 될 것으로 예상했다.기대와 달리 실패를 하였다. 첫번째 테스트(ofWithOrderDetail)의 productId의 값이 2L 되었다. 뭐야.. 왜..? 처음에는 롤백이 안됐나? 생
📖 @CreatedDate, @LastModifiedDate은 테스트를 어떻게 해야할까? @CreatedDate, @LastModifiedDate은 JPA에서 처리해주는 녀석들이라서 테스트 작성시 어떻게 테스트해야 할까 고민이 많았다. (현재 @CreatedDate
Service에 필요한 모든 정보들을 mock 처리 해주면 가능하다.이게 무슨말이냐? 바로 코드를 보자현재 내가 사용하는 Service는 다음 필드들을 필요로 한다.이 모든 것을 모킹을 해주어야 한다는 뜻이기도 하다.(다른 이야기지만 현재 서비스에서 책임이 많아보인다.
04 개발일지를 보고 올 것을 추천드린당.앞에서 말했다시피 커맨드와 쿼리를 분리했기 때문에 mock 객체를 따로만들었다. 자연스레 같은 데이터 저장소를 참조 할 수 없게 되었다.어떻게 해결해야 할까?이런식으로 부모의 필드에 공유값을 넣고 super로 접근해서 사용하면
📖 DTO 구조에 대한 문제점 인식 필요한 이름으로 작성하다보니 팀원이 원하는 Dto명과 이미 내가 작성한 Dto명이 겹치게 되었다. 일단 나도 컨벤션없이 그럴듯한 이름으로 작성하다보니 뭐가 뭔지 모르는 현상까지 되어버렸다... 이러한 문제점을 인식하고 깔끔한 d
패키지, 소스코드 리팩토링 후 restdocs를 리팩토링 하려는데 다음과 같은 오류가 났다.에러에 겁이 낫지만 찾아보니 별거 아니었다. 기본생성자가 없기 때문이었다.기존에 없었던 @NoArgsConstructor를 추가하여 기본 생성자를 만들어 주었다!