강의를 수강하면서 2가지 질문이 생겼습니다

안녕하세요. 지식공유자 쥬쥬입니다!말씀하신대로, 브릿지 네트워크를 이용해 구성하시는 것도 가능합니다.강의를 시청하시는 분들이 최대한 오류없이 그대로 따라하실 수 있도록 위처럼 강의를 제작했습니다!감사합니다.

lombok 설정에서 오류가 발생해요

안녕하세요 지식 공유자 쥬쥬입니다! 혹시 IntelliJ에서 annotation processing이 enabled 되어있는지 확인 부탁드려요!감사합니다.

2 -1 lombok 설정에서 오류가 발생해요

안녕하세요! 지식공유자 쥬쥬입니다. 혹시 인텔리제이의 어노테이션 프로세서 설정이 되어있으실까요?

github action

안녕하세요 ! 지식공유자 쥬쥬입니다. JOB의 실행 주체는 크게 두가지로 나늬워지는데요.Managed RunnerSelf-Hosted Runner저희는 별도의 설정을 하지 않기 때문에 깃헙에서 제공하는 Managed Runner (서버 인스턴스)를 사용합니다.이곳에는 별도의 JDK가 설치되어 있지 않기 때문에 JDK 설치 과정이 필요합니다. 감사합니다 !

put api 500 서버에러응답 문제

안녕하세요 ! 지식공유자 쥬쥬입니다. 상세한 답변을 위해 로그 첨부 부탁드려요 ! 감사합니다.

스프링 버전

안녕하세요 ! 지식공유자 쥬쥬입니다. 스프링 버전 1과 2는 스프링 부트 버전 말씀하시는 것이 맞으실까요? 저도 그렇게 사용해본 경험은 없지만 이론상 가능하다고 생각합니다. 스프링 부트 2 버전에서는 junit5를 사용하더라도 큰 문제가 없을 확률이 높지만, 1버전에서는 스프링부트에서 관리하는 라이브러리들의 버전과 충돌이 우려되기 때문에, junit 이전 버전을 사용하시는 것을 권장드립니다. 현재 저희는 3버전을 사용하고 있지만, 2버전에서도 junit5를 무리 없이 사용했던 경험이 있습니다. 또한 2버전에서는 2버전으로 올릴 때 큰 breaking point가 없기 때문에, 버전 올리는 것도 어렵지 않을 수 있습니다. 감사합니다 !

서비스 메소드 작성 시 질문!

안녕하세요. 지식공유자 쥬쥬입니다 ! 대부분의 로직은 Domain Model 안에서 작성하는 것을 권장합니다. 일반적으로 아래와 같은 느낌으로 사용하고 있습니다.ApplicationService (Primary Port) -- 사용 --> DomainService / DomainModel / Repository (Secondary Port) 저는 잘 추상화된 것이 아니라면 서비스와 메소드의 depth를 늘리는 것을 선호하는 편은 아닌 것 같습니다. 궁금하신 용어들은 검색 해보시고 모호한 것들 추가로 문의주시면 감사합니다 ! 감사합니다.

2-3 진행 중 에러 발생

안녕하세요 ! 지식공유자 쥬쥬입니다. 혹시 Exception Log를 첨부해주실 수 있으실까요? 감사합니다.

RestaurantApi 컨트롤러 개발 질문

안녕하세요. 지식공유자 쥬쥬입니다. 현업에서는 일반적으로 Scalar 값으로 넘기거나 객체 컨버팅을 한번 더 하여 메소드를 호출합니다. 예를 들어서, Request 객체가 있다고 가정했을 때 아래처럼 한번 컨버팅 하거나, 인자값을 풀어 사용하는 형태입니다 ! FooBarReqeust -> method(FooBarCommand/Query)FooBarRequest -> method(propert1, proeprty2) 일반적으로 Request객체에서 아래처럼 바꾸어줍니다. class FooBarRequest { String proeprty1; String property2; public FooBarCommand toCommand() { return new FooBarCommand(property1, property2); // builder가 있다면 builder 사용 } } 감사합니다 !

변경데이터 저장 방법 질문 있습니다!

안녕하세요. 지식공유자 쥬쥬입니다. 이전에 비슷한 질문이 있었어서, 첨부합니다 ! 감사합니다. 안녕하세요 지식공유자 쥬쥬입니다! 말씀하신대로 JPA에서는 영속성컨텍스트에 있는 Entity의 더티체킹을 통해 update 쿼리를 날려주므로 save() 메소드를 호출하지 않아도 데이터베이스에 반영됩니다! 좋은 말씀이신 것 같습니다! 하지만 이것은 JPA Native한 기능(spring-data-jpa가 가지고 있는 특징이란 뜻입니다!)으로, @Repository의 save() 메소드를 명시적으로 호출해주는 것이 특정 상황에서는 좋을 수 있습니다. 예를 들어, 다음과 같은 요구사항이 생겼다고 가정해볼게요!JPA로 선언한 Entity를 다른 spring-data 라이브러리로 교체할 경우 (mongo db나 r2dbc와 같은)이 때 JPA를 사용할 때에는 동작했던 코드들이 단순히 spring data 구현체를 교체함으로써 동작이 안하는 상황이 발생할 수 있습니다! 사실 위같은 상황은 많이 발생하지는 않습니다. 저 같은 경우에는 메모리에 있는 객체의 상태가 변경되었다면 저장소(Repository)에 다시 저장(save)해주는 코드가 명시적으로 있는 것이 조금 더 "자연"스럽다고 느껴지는데요. 이것은 제 느낌일 뿐 개개인이 모두 다르게 느낄 수 있다고 생각합니다. 인프넌님이 위같은 견해들을 함께 생각해보시고, 더 낫다고 판단되는 방향으로 개발하시는 것이 가장 좋다고 생각합니다! Appendix.JPA의 더티체킹 기능은 마틴파울러의 저서 엔터프라이즈 애플리케이션 아키텍처 패턴 (P of EAA)의 작업 단위(Unit of Work) 패턴을 읽어보시면 이해하기가 더욱 좋으실거에요! https://www.inflearn.com/questions/939276/%EB%A7%9B%EC%A7%91-%EC%88%98%EC%A0%95-api-%EC%A7%88%EB%AC%B8%EC%9E%85%EB%8B%88%EB%8B%A4