묻고 답해요
169만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결스프링 핵심 원리 - 기본편
섹션3. 11 회원객체 다이어그램
[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]회원 객체 다이어그램에 클라이언트 -> 회원서비스 구현체 -> 회원저장소 이렇게 되어있는데 클라이언트는 구현체는 인터페이스에 의존해야하잖아요?근데 왜 클래스 다이어그램에도 그렇고 객체 다이어그램에도그렇고 클라리언트 -> 회원서비스 구현체 -> 회원 저장소 이렇게 되어있는건가요???
-
미해결스프링 핵심 원리 - 기본편
OCP, DIP과 @Qualifier 어노테이션에 대해서 질문합니다.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]안녕하세요. 좋은 강의 재미있게 잘 듣고 있습니다. 특별히 오류가 발생한 것은 아니고 강의를 수강하다가 한 가지 궁금한 점이 생겨 질문 남기게 되었습니다.강의 앞 부분에서 OCP, DIP 같은 객체 지향 설계 원칙에 기반해서 DiscountPolicy 같은 것들은 인터페이스를 두고 실제 구현 객체를 구현하고, 그 구현 객체를 빈 객체로 등록하여 의존성을 주입 받으면서 코드를 작성해왔는데, 결국 @Qualifier 어노테이션을 통해 2개 이상의 구현 객체 중 한 가지를 지정하게 되면 인터페이스에 의존하는 것이 아닌 실제 구현 객체에 의존하게 되면서 OCP, DIP 같은 원칙에 위반되는 것이 아닌가? 이런 궁금증이 생겨서 질문합니다!
-
미해결실무 환경 그대로 주문게시판 만들기 웹개발 기초 마스터
강의 연장 요청
안녕하세요!강의 연장이 가능할까요?확인 부탁드립니다!
-
미해결스프링 DB 2편 - 데이터 접근 활용 기술
설정 정보 없이 임베디드 데이터베이스 생성
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]스프링이 설정정보 없이 H2 데이터베이스 커넥션을 연결할 때 build.gradle에 dependencies 에 있는 H2를 읽고 커넥션을 연결하나요?
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
형 이번에 낸 책이랑 강의 내용에 차이가 있어?
교보 앱 보다가 형이 낸 책을 발견 했는데 이 강의랑 내용 차이가 있어서 읽는걸 추천하는지 궁금해책 출간한거 축하해
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
형 나 몰래 책내면 모를 줄 알고?
형 나 매일마다 교보 눈팅하는 데 형 책 나와서 깜짝 놀랐잖아! 축하해~ 책쓰는 거 엄청 힘든데 고생했어~ https://product.kyobobook.co.kr/detail/S000219973675
-
미해결실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발
OrderServiceTest 상문주문 테스트 시 update 쿼리 문의
안녕하세요.OrderServiceTest에 상문주문 메서드 실행 할때 쿼리를 봤는데 item에 update 쿼리가 발생했더라고요. 제가 궁금한게 item, member, order.. 등등 persist 했고 중간에 flush를 할만한 jpql이라던가 모든 엔티티 pk가 identity로 되어 있지 않은데 item에 update가 왜 발생한건가요? 엔티티를 persist 하고 flush 전에 변경 감지 set으로 수정하면 insert -> update가 나가는건가요? insert만 나가는거 아닌가요?감사합니다.
-
해결됨토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
N+1 관련해서 질문있습니다.
안녕하세요. 우선 좋은 강의 제작해주신 토비님께 항상 감사하고 있어요. 이제 배운지 1년된 왕초보입니당..혼자 배워보면서 개인 프로젝트를 만들고 있는데 JPA를 사용하고 있어요.제가 궁금한 것이... N+1 관련한 문제입니다. 아 일단 프로젝트 주제는 복식부기 가계부에요. @Entity ... public class Journal extends BaseEntity { @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "ledger_id", nullable = false, updatable = false) @OnDelete(action = OnDeleteAction.CASCADE) private Ledger ledger; ... @OneToMany(mappedBy = "journal", fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true) private List<EntryLine> entries = new ArrayList<>(2); ... public EntryLine getEntryLine(EntrySide side) { switch (side) { case CREDIT : this.entries.stream().filter(line -> line.isCredit()).findFirst() .orElseThrow(...); case DEBIT : this.entries.stream().filter(line -> line.isDebit()).findFirst() .orElseThrow(...); default : throw new ... } } ... // Service에서 저장되기 전에 호출 public void validateSavable() { ... validateJournalSave(); } private void validateJournalSave() { AccountType debit = getEntryLine(EntrySide.DEBIT).getAccountType(); AccountType credit = getEntryLine(EntrySide.CREDIT).getAccountType(); if(!this.transactionType.isValidPlacement(debit, credit)) { throw new ... } } }Journal Class에서 EntryLine List에 접근하고 있어요. 그리고 EntryLine Class는 이렇게 생겼어요.@Entity ... public class EntryLine extends BaseEntity { @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "journal_id", nullable = false, updatable = false) private Journal journal; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "account_id", nullable = false) private Account account; ... // private package 접근제어자 사용 // Account는 Category를 참조중이에요. AccountType getAccountType() { return this.account.getCategory().getAccountType(); } } 거래가 저장되기 전에 Journal : validateJournalSave() 에서 this.transactionType에 따라 차변과 대변에 올바르게 위치하고 있는지 검사한 후 저장하고 있는데 이것을 생성과 수정할 때 두 곳에서 사용하고 있어요. Ledger에 5개 Category가 있고, Account는 그 Category를 참조하고 Category에서만 AccountType이 있어요.Journal이 각 EntryLine의 AccountType을 얻기 위해Journal -> EntryLine -> Account -> Category -> getAccountType() 이렇게 흘러가네요.이렇게 접근해도 설계상 괜찮은걸까요? Journal을 저장할때는 @Query 사용해서 Fetch Join으로 필요한 Account를 가져오고 있는 상황이에요.Journal이라는 엔티티가 비즈니스 로직 수행을 위해서 다른 엔티티의 필드까지 깊게 참조?? 가져오도록 설계하는게 옳은건지 모르겠어요.
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
강의 중복 확인 요청
섹션 9부터 중복으로 내용이 있는데 확인 바란다
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
중복내용 제보?!
안녕 킬구형 강의는 구매한지 오래됐지만 지금에서야 공부하고 있어 별건 아닌데! 청크처리와 트랜잭션 부분이 2번 들어가있어서 알려줄려고! 킬구형 덕분에 싸게 구매해서 정말 공부 열심히 하고 있어!다음것도 기대할게!
-
해결됨카카오 면접관의 실무 밀착형 Spring Batch: 대용량 데이터 처리의 모든 것
여러 파드 환경에서 단일 실행 보장 방식
단일 실행이 보장되는 이유로 Db를 통해서 값을 가져오고 있으며 db에서 동시성을 방어해주고 있기 때문이라고 해주셨는데요.FindRunningJobExecutions 는 단순 select문이 아니고 내부적으로 비관적 락으로 동시 접근을 막아주는 구조인가요? 저는 여러 파드인 상황에서는 보여주신 코드가 동시성 이슈로 인해 주어진 잡이 한 번만 실행된다는 것을 보장하기 힘들 것 같다고 생각했습니다.이외에도 여러 파드인 상황이라면 실무에서 어떤 요소를 고려하는지 궁금합니다.학습 내용에선 currentimestamp를 잡 파라미터에 넣어서 매번 새로운 잡 인스턴스로 취급/실행하는 형태를 보여주셨는데, 이로인해 멀티파드 환경에서 특정 잡의 중복 실행 방지 혹은 특정 잡 파라미터 구성에서의 중복 실행 방지에 대한 요건 구현 시 영향도/고려 사항이 있는지 여부와 아니면 currentimestamp 잡 파라미터를 실무에서 빼기도 하는지 궁금합니다운영 시 중복 실행 문제 및 잡 재시도에 대해 고민하다 나온 질문입니다. 혹시 애초에 대부분의 배치 잡과 스탭 로직을 멱등하게 동작하도록 설계 및 코드 작성을 해야하는 걸까요?
-
미해결자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]
패키지 구분에 대해 궁금한게 있습니다
요즘은 domain별로 패키지를 나눈다고 들었는데 강의에서는 역할별로 패키지를 나누고 있어서요.어떻게 나누는게 좋은건가요?!\
-
미해결스프링 핵심 원리 - 기본편
코드 자료
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]강의 자바 코드 자료는 따로없을까요?
-
해결됨6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법
조회속도 개선에서 더 개선하는 방법이 궁금합니다.
안녕하세요. 인덱스를 활용한 조회 성능 개선을 공부하던 중 궁금한 점이 생겨 질문드립니다.현재 저는 OFFSET 기반 pagination을 사용하는 서비스를 개발하고 있으며, 다음과 같은 환경에서 성능 테스트를 진행했습니다.데이터: 약 1,000만 건서버: EC2 t3.smallDB: RDS t4g.microk6 vus1001. 문제 상황초기에는 OFFSET 제한 없이 마지막 페이지까지 이동 가능하도록 구현했습니다.하지만 데이터가 1,000만 건 수준으로 증가하자, 깊은 페이지로 갈수록 조회 속도가 급격히 느려지는 문제를 확인했습니다.2. 고민 및 제약일반적으로 이 문제는 Keyset Pagination(커서 기반)으로 해결하라고 많이 알려져 있습니다.하지만 제 서비스는👉네비게이션 바를 통한 페이지 직접 이동 (ex. 1, 10, 100 페이지 클릭)이 필요하기 때문에 Keyset 방식만으로는 요구사항을 만족시키기 어렵다고 판단했습니다.3. 적용한 개선 방법다음과 같은 방식으로 성능 개선을 진행했습니다.OFFSET 최대 범위를 제한 (최대 10,000 페이지 / OFFSET 100,000)커버링 인덱스 적용조회 방식 개선먼저 ID만 조회 → 이후 필요한 10건만 상세 조회전체 게시글 수(count)는 캐싱 처리4. 성능 개선 결과[Page 10] avg: 1.4s → 700ms p95: 4.5s → 1.8s [Page 100] avg: 17s → 1.18s p95: 24s → 3.3s [Page 1000] avg: 32.1s → 1.7s p95: 59s → 4.27s SQL 쿼리는 분석결과 약 1700MS -> 70MS 까지 단축한 것 같습니다.5. 추가 제약사항로그인 사용자와 비로그인 사용자의 조회 결과가 다름(사용자별 구독 게시글이 포함됨)따라서 캐시는 비로그인 사용자에만 적용위 성능 수치는 로그인 사용자 기준6. 현재 고민위와 같이 개선했지만,👉 여전히 성능이 충분하지 않다고 느끼고 있습니다.특히 궁금한 점은 다음과 같습니다.7. 질문OFFSET 기반 pagination을 유지하면서👉추가로 성능을 개선할 수 있는 방법이 있을까요?다음과 같은 방법들을 고려했는데, 방향성이 맞는지 궁금합니다.RDS를 2개를 사용하여 조회 성능 데이터를 각각 2개의 db가 처리하도록 한다?Keyset + OFFSET 혼합 방식(일반적인 페이지 이동은 Keyset Pagination을 사용하고,사용자가 특정 페이지를 직접 입력하거나 점프하는 경우에만제한적으로 OFFSET 기반 조회를 사용하는 혼합 방식)RDS 스펙 업그레이드또한 에펨코리아(https://www.fmkorea.com/)와 같은 대형 커뮤니티는 제가 원하는 페이지 네이션 방식을 사용하면서 깊은페이지(최대 1만)도 지원하고동시접속자 수십만페이지 수천~수만대량 데이터환경에서도 빠른 조회 성능을 유지하는데👉이러한 서비스들은 어떤 방식으로 pagination 및 조회 성능을 처리하는지 궁금합니다.
-
미해결스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술
servlet과 container에 대한 질문입니다
안녕하세요.servlet에 대해서 공부하고 있는데 servlet container는 servlet의 생명주기를관리한다라고 알고 있습니다. 그런데 controller 같은 경우는 spring 컨테이너에서 관리하는 것으로 알고 있습니다.그러면 servlet container는 dispatcherservlet만 관리하고 controller는 spring container에서 관리하는 걸까요? 그리고 servlet, controller의 차이는 무엇인가요?
-
미해결스프링 DB 2편 - 데이터 접근 활용 기술
RepositoryTest의 패키지 위치가 domain인 이유
[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]안녕하세요, 영한님.ItemRepositoryTest 파일의 위치가 hello.iitemservice.repository가 아니라, hello.iitemservice.domain임을 확인했습니다.제 생각으로는 단순 패키지 구조 오타로 인해 domain에 위치된 것이라고 여겨지는데요. 혹시 의도적으로 domain 패키지 하위에 두신 건지 궁금합니다!
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
도메인 모델에서 관계와 규칙을 구분하는 방법
안녕하세요. 도메인 모델을 설명하는 부분에서 관계와 규칙을 온라인 서점 운영 예시로 간단히 언급해주셨습니다.강의를 들으면서 실제 업무 도메인에 관계와 규칙을 구분지으며 간단히 개인 실습을 해보았는데요.적다보니 어느샌가 관계에 규칙이 섞이기도 하더라고요. 문득 이런 생각이 들었습니다. '관계와 규칙의 차이는 무엇인가?'관계와 규칙을 명확하게 구분지으려면 어떤 기준을 갖고 생각해야할까요? 관계는, DB 모델에 워낙 익숙하다보니 하나의 OO은 여러 OOO을 갖는다. 이쪽으로 먼저 생각이 흐르기도 하고요. 예시로 들어주신 것을 보면 관계는, '비즈니스에서 관계'라는 생각이 듭니다. 규칙은 데이터를 변경할 때 필요한 조건이라고 생각하면 될까요?토비님 의견이 궁금합니다.
-
미해결Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트
UserService, CertificationService 책임 분리 기준 질문
UserService 가 회원 생성이라는 유즈케이스를 담당하는데, 인증 url 생성이나 메일 발송 정책까지 함께 가지고 있기 때문에 책임이 섞여있다고 판단하여 CertificationService 를 분리하신걸까요? 단순히 외부 의존성 분리하려는 목적보다는 인증메일 정책 이라는 별도의 변경 이유를 분리하려는 의도가 맞는지 궁금합니다
-
미해결스프링 DB 1편 - 데이터 접근 핵심 원리
spring initialiser 어떤걸 선택해야될지 모르겠어요
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오) 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)예[질문 내용]여기에 질문 내용을 남겨주세요. 안녕하세요.spring db 1편 들으려 하는데초기 설정이 강의랑 많이 다르네요Gradle groovy, Gradle kotlinSpring boot (4.05 vs 3.5.13)java 21 vs 17등 어떤 것을 선택해야할지 모르겠어요
-
미해결스프링 핵심 원리 - 기본편
구현체가 동적으로 정해질 때, 팩토리 기법을 사용하나요?
[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예[질문 내용]1. 현재 FixDiscountPolicy와 RateDiscountPolicy는 동적으로 바뀌는 것이 아니라, 만약 실행 중에 정책이 바뀌면 서버를 끄고, 코드를 수정하고 다시 올려야 합니다. 하지만 만약, 사용자가 동적으로 둘 중에 선택을 할 수 있다고 가정한다면은, 즉 FixDiscountPolicy와 RateDiscountPolicy 모두 @Bean으로 관리되고 사용자의 선택으로 어떤 구현체가 쓰일 것인지 정해진다면, 팩토리 기법으로 사용하는게 올바른 것일까요? 예를 들어 discountPolicyFactory가 생성될 때, discountPolicy 인터페이스를 구현한 구현체들 모두 map(빈 이름, 빈 객체) 형태로 Factory에 등록한 후에, 사용자가 선택할 때마다 FixDiscountPolicy라는 빈 객체가 반환되도록 하는 것입니다.2. 혹은 요즘 실무에서는 이런 상황에서 팩토리 기법 말고 또 다른 방법이 존재하는지에 대해서도 여쭤보고 싶습니다.감사합니다.