해당 코드는 현재진행중인 프로젝트의 couponPolicy dto코드다. 일반적으로 dto class에는 @Getter, @NoArgsConstructor 정도를 써주고 나머지는 프로젝트를 진행하면서 상황에 맞게 사용해주면 될 것 같다.

보이는 것처럼 각 Entity class마다 적용하기로 함. 물론 어쩔 수 없이 변형해야한다면 관용을 주어서 허용함.그렇다면 왜 해당 어노테이션을 기준으로 entity class를 적용할까에 대한 이유를 적어봄.값을 가져올려면 무조건 필요함. @Getter말고 @Set
현재 프로젝트에서 사용하고있는 dto들인데 해당구조를 그대로 사용할 것인지 아니면 java14에서 추가된 record 타입으로 바꿀것인지 조원들과 토의함.위에 올라온 코드형식을 보일러플레이트코드(Boilerplate Code)라고 함. 간략하게 설명하면 최소한의 변경
프로젝트 초입에 프로젝트 패키지 구조에대한 논의를 하게됨.계층구조냐 도메인구조냐 논의끝에 도메인구조로 하기로 결정함.왜 도메인 구조를 선택하였냐면 기존 계층형구조에서는 웹을 계층으로 나누어 (controller, service, repository와 같은 층으로 나눔.
왜 service layer에 @Transactional을 쓰는지 간략하게 설명하자면 다음과 같음.1\. web의 layer마다 역할이 다다름. 그 중 service layer에서 비즈니스 로직을 관리하기때문에 @Transactional을 사용함.2\. @Transac
해당 메소드를 프론드단에서 적용하여 coupon api로 보내주는걸 목표로 했는데 작동이 되지않는다.원인을 보아하니 feign은 patch를 지원하지 않는다고 함.따라서 다음과같은 설정을 해주어야함⚙️ 출처: https://ystc1247.tistory.com

보이는 것처럼 search 버튼을 누르면 해당 검색옵션값과, 검색내용을 가져오는것을 확인 할 수 있다.

fixed rate, cron
dto에 다른 dto를 넣음으로써 의존성증가됨이를 해결하기위해 dto분리...

단순히 스웨거를 통해 html을생성해본것이아니라 동적으로 배포서버에 실시간으로 feignclient호출하여 값을 가져옴 custom도 가능하게함 spring doc은 왜안썼는지 ? 테스트코드 다하기전이라.... 그리고 디자인별로....

기존 쿠폰에서 테이블 과감히삭제 아쉬운점 msa관점에서 멀어짐 쿠폰자체의 테이블이 없음...

프론트서버를 왜 이중화해야할까? 오리탕 북스토어 프로젝트 서버를 nhncloud에 배포하면서 front 서버를 이중화해야하는 요구사항을 해결하기위해 다음과 같은 nginx.conf 파일을 ubuntu환경의 server에 작성함. 이렇게 파일을 작성하고 github

북스토어 프로젝트https://github.com/nhnacademy-be6-5ritangnhnacademy 수료를 하기 직전 최종 프로젝트로 북스토어 프로젝트를 진행했다. 해당 프로젝트는 약 2달에 걸쳐 진행되었고 아카데미측에서 제공해준\--유익했던거깃허브
프로젝트 진행중에 feignclient 적용하여 쿠폰생성api를 불러오는중에 다음과같은 파라미터 오류가 나옴. 해당원인은 feignclient는 단독으로 String userId 매개변수를 줄 수가 없음. 따라서 @requestparam, @pathvariable을