수업 예시에서는 외부 api가 실패할 경우 스케쥴러를 활용해서 후보정 로직을 통하여 결과적 일관성을 맞추고 있습니다. 만약에 자리를 지정하는 콘서트를 위와 같이 처리할 경우 (예약은 성공, 외부 api는 실패), 후보정 로직이 동작하기 전 다른 예약 시스템에서 해당 자리를 예약한 경우 더욱 큰 문제가 발생할 수 있을 것으로 보입니다. 이러한 경우 (좌석처럼 한정된 자원을 예약하는 경우), 외부 API 실패 시 후보정 로직을 통한 비동기 처리 대신 동기적으로 처리하는 것이 올바른 방식인 것 같은데, 강사님은 어떻게 생각하시는지 궁금합니다!
[질문 내용] 안녕하세요. 17강에서 와일드카드 공부 중인데, 갑자기 와일드카드 예시에서 기존에 제네릭 예제에서는 사용하지 않던 문법들이 보여서요. 와일드카드를 쓰지 않는 제네릭 메서드인데도 갑자기 메서드 선언 방식이 바뀐 것 같아요. 왜 기존에는 반환값으로 <T> T 를 적었는데 왜 이번 강의에서는 <T> 만 적는 것인지 모르겠어요. 그리고 이전에는 파라미터로 T t 를 넘겼는데, 왜 지금은 Box<T> box 를 통째로 넘기는 것인지도 이해가 안 가요. static <T> void printGenericV1(Box<T> box) { System.out.println("T = " + box.get()); } 이전 제네릭 강의에서 사용한 방식 public <T> T printAndReturn(T t) { System.out.println("animal.className: " + animal.getClass().getName()); System.out.println("t.className: " + t.getClass().getName()); return t; } 감사합니다.
revalidatePath("/about", "page") 로 설정을 하고 테스트를 하다 보면 /about 페이지에서 재검증 버튼을 누르면 AboutLayout의 데이터 패칭 결과와 AboutPage의 데이터 패칭 결과가 함께 바뀌는 것과, /about/detail 페이지에서 재검증 버튼을 누르면 아무런 변화도 없는 이유가 revalidatePath의 첫 번째 인자로 설정된 "/about" 이 아닌 /about/detail 페이지에 접속해 있기 때문이라는 것까지는 이해했습니다. 하지만 detail 페이지에서 재검증을 누르고 about 페이지로 이동하면 즉시 AboutPage의 결과는 변하는데 AboutLayout의 결과는 변하지 않는데 이유가 뭔가요?
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] Delivery에 있는 @OneToOne(mappedBy = "delivery", fetch = LAZY) private Order order; 에서 인텔리제이가 fetch = LAZY에 노란줄이 떠서 확인해보니 Specifying FetchType.LAZY for the non-owning side of the @OneToOne association will not affect the loading. The related entity will still be loaded as if the FetchType.EAGER is defined. 이런 메세지가 뜹니다. 찾아보니 Lazy를해도 Eager로 동작한다는 거 같은데.. 실제로 테스트를 해보니 Eager로 동작 하고 있어서 여기에 OneToOne인데 lazy로 동작해도 상관없는걸까요?? 아니면 제가 어떤걸 놓친건지 궁금합니다
[질문 내용] 여기에 질문 내용을 남겨주세요. { private final Random random = new Random(); private int[] lottoNum; private int count; public int[] generate() { lottoNum = new int[6]; count = 0; while (count < 6) { //1-45 숫자 생성 int num = random.nextInt(45) + 1; //중복 제거 필요 if (isUnique(num, count)) { lottoNum[count] = num; count++; } } return lottoNum; } public boolean isUnique(int num, int count) { if(lottoNum[count]==num){ return false; } else {return true;} } } isUnique 메서드를 이렇게 작성하면 중복제거가 안 되는 이유가 뭘까요
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 접근제어자 - 쇼핑카트 문제에서 장바구니 상품출력 메서드인 displayItems()와 전체 가격 합을 구하는 calculateTotalPrice() 이거로 나누셨는데, 나누는 이유는 유지보수(나중에 소스 수정) 하기에 좋아서 나누셨겠죠? 근데 만약 안나눈다고 가정한다면.. 이런식으로 한 메서드 안에 넣어도 되는 것인지 궁금합니다. 실행 결과는 똑같이 나옵니다. 감사합니다.
안녕하세요. 좋은 강의 잘듣고 많이 배우고 있습니다. 좋은 강의 만들어주셔서 감사합니다. 다름이 아니라, 어댑터에서 엔티티에 의존성을 가지는 것이 크게 문제되지 않는다고 말씀주신 내용에 의문이 있어 질문드립니다! 어댑터에서 도메인에 직접 의존하는 것을 막기 위해서 변환 역할을 하는 매퍼 클래스나 DTO에서 엔티티를 자기 자신으로 변환하는 로직을 가지는 것은 어떨까요? 타이트하게 룰을 잡는 케이스를 가정한다면, application layer 내부에 port가 존재할 것이고 이 port에서 return 하는 dto도 application layer일 것이고, 이 dto 안에서 Entity를 받아서 자기 자신으로 변환하는 로직을 가진다면 entity가 application 밖으로 나가지 않을 수 있지 않을까요? (controller, repository 등 마찬가지입니다) 그리고 dto를 application에서 변환하는 것이 로직의 침투라고 표현하시기도 했는데, 그렇다면 provided port 역시 어댑터의 요구가 침투하는 구조라고 볼 수도 있을 것 같기도 합니다.. (생각해보니 이상적으로는 계층별로 DTO를 생성하는게 맞다고 생각은 들지만, "엔티티를 반환하는 트레이드오프가 굉장히 효율적이고 정당하다"라고 말씀하신 것 같다고도 생각이 듭니다) 강의에서 항상 기술이 등장한 배경과 사상을 이해하고, 이를 바탕으로 정당하게 규칙을 스스로 정하는 것을 강조하시는 것 같습니다. 그래서 강의에서 말씀하신 내용이 비슷한 맥락으로, "절대 노출되면 안된다"라는 것에 대한 반박이라고 받아들여지긴 합니다만.. 그래도 바깥쪽으로 노출하지 않는 것이 의존성 관리 차원에서 더 좋지 않을까하는 생각에 질문드립니다!
useEffect를 통해 setErros를 호출해서 errors 상태를 변경하고 있습니다. 상태를 변경하는 건 부수효과가 아니니까 useEffect에서 상태 업데이트는 잘못된 사용이 아닌가 해서요! 저것 때문에 렌더링이 두 번 되기도 하고, https://react.dev/learn/you-might-not-need-an-effect#updating-state-based-on-props-or-state 이 내용이랑 같은 내용인 것 같아서요!
혼자서도 해보고 '레이아웃 분리하기 - 풀이' 강의를 보고 똑같이 해도 (with-layout) 그룹에 생성한 Layout(MainLayout)은 아래와 같이 MainLayout 하위에 MainLayout이 또 있는 것처럼 뜨는데 이건 정상적인 건가요? (auth) 그룹에 생성한 Layout(AuthLayout)은 아래와 같이 AuthLayout이 하나만 있어서 어떤 게 정상인지, 원래 이런 건지 알고 싶습니다. 프로젝트 폴더 구조는 다음과 같습니다:
죄송합니다 또 궁금한게 생겨서 여쭈어봅니다 ai에게 물어봐도 항상 이게 진짜 맞는건지 의문이 생겨서 만약 프론트 쪽에서만 next js 에서 헤더랑 쿠키에 접근을 할 일이 그렇게 있을가 하는 의문이 생겨서 질문드립니다. 백엔드가 기본적인 확인을해서 처리를 하고 권한 이나 그런건 api호출을 하면 되지않을가라는 의문이 들어 질문 남깁니다
안녕하세요 수코딩님 갑자기 의문이 든 생각인데 next js 는 보면 프레임워크라서 여러 기능을 제공하고 편리하게 사용할수있는것같습니다 seo문제도 해결해주고 무엇보다 use client를 사용하면 클라이언트 컴포넌트로서 작동도 되고요 근데 그럼 의문이 드는게 둘다 가능하고 선택가능한 next를 쓰는게 무조건 이득이 아닌가 라는 생각이 들엇습니다. 그냥 서버사이드쪽만 서버사이드 좀하고 리액트가 필요한쪽은 클라이언트 사이드 렌더링으로 하면 되는 이야기인것같아서요
예제에서는 도메인에 별도 PasswordEncoder 인터페이스를 정의해 사용하고 있습니다. 만약에, Member 도메인이 Spring Security의 PasswordEncoder 인터페이스를 직접 의존한다면, 구현체가 아니라 인터페이스를 참조하더라도 순수 도메인 설계 관점에서 위반으로 봐야 할까요? 저는 인터페이스 의존이라 괜찮을 수 있다고 생각했지만 AI는 도메인에서는 자체 PasswordEncoder 포트만 사용하고, Spring Security PasswordEncoder는 인프라 어댑터에서 위임하는 것이 좋다. 고 제안했습니다. 토비님은 어느 쪽이 더 적절하다고 보시는지, 판단 기준도 함께 듣고 싶습니다.
