public Reservation reserve(Customer customer, int audienceCount) { Money fee = movie.calculateFee(this).times(audienceCount); return new Reservation(customer, this , audienceCount, fee); } reserve 하기위해 movie에게 calculateFee를 하기 위해 screening을 전달해주는데 이 전달해주는 명확한 근거가 있는지 궁금합니다. 만약 screening을 전달하지않고 빈 것으로 전달했다하더라도 public Money calculateFee(Screening screening) { return fee.minus(discountPolicy.calculateDiscount(screening)); } Movie 클래스에서 screening 대신 movie를 this로 전달했어도 동일한 기능은 가능한 거 같습니다. 질문을 하다가 깨달았는데 DiscountCondition에 screening이 필요하기 때문에 전달해주는 것을 알게되었습니다. 이렇게 전달해주는 것은 자연스럽게 일단 관계와 책임을 결정한 뒤 필요한 요소들이 뭘까 전체적으로 고민하면서 정해지는 것일까요? 상영이 예약에 대한 책임을 지고, 영화에게 가격을 계산하는 책임을 줄 때 screening을 넘겨주는 것과 condition에서 screening이 필요하다는 것까지 같이 설계하셨었는지 궁금합니다.
안녕하세요 영한님! 이전 게시글에서 질문의 연장선 느낌이지만, 별도의 주제인 것 같아서 글을 따로 남깁니다. 강의에서 주문은 '결제'까지 포함하는 비즈니스 트랜잭션의 단위이고, 배송은 '물류'라는 별개의 프로세스다 라는 이유로, 주문 엔티티와 배송 엔티티를 분류하였는데요. 엔티티를 분리할 수 있는 기준을 어디까지 고려해야 하는지 궁금합니다. Application 예를 들면, 회원 (이메일, 비밀번호, 실명, 닉네임, 성별) 엔티티가 있다면, Application Server에서의 인증/인가 프로세스를 고려하여, (이메일, 비밀번호), (실명, 닉네임, 성별) 이라는 별개의 엔티티로 분리할 수 있을 것 같거든요. 이런식으로 Application 을 고려해서 설계를 해도 괜찮을까요? 화면 또 다른 예를 들면, 배달의 민족에서 가게 를 생각해보면 가게 목록 페이지에서는 가게의 전화번호, 주소 같은 정보는 보여주지 않고, "가게 정보" 라는 페이지에서만 구체적인 가게 정보들을 보여주는데요. 만약 가게 와 가게 세부 정보 라고 따로 분리한다면 가게 목록 페이지를 구성할 때 가게 세부 정보 는 읽지 않고 가게 컬럼만 접근할 수도 있을 것 같습니다. 이런식으로 엔티티를 분리하였을 때 얻는 이점도 존재할 것 같고, 복잡도가 증가한다는 단점도 존재하는 것 같습니다. 처음에는 비즈니스 요구사항에 초점을 두고 모델링하고, 개발을 진행하면서 엔티티 설계를 조금씩 바꾸는게 좋을까요? 처음부터 너무나 많은 걸 고려하면 오버엔지니어링이 되거나 유연성이 떨어질 것 같고, 반대의 경우에도 나중에 Application 코드를 바꾸는 데 많은 자원이 필요할 것 같습니다. 영한님의 생각은 어떠신지 궁금합니다.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 만약 무한정 대기할 수도 있는 상황에서 t1.join(50); t2.join(50); main의 코드를 이렇게 바꿔봤는데 결과가 똑같더라구요 이게 왜 그런지 알고 싶습니다.
안녕하세요 영한님! 강의를 들으면서 쇼핑몰 요구사항을 조금 더 확대해서 직접 모델링해보고 있습니다. (Store, Delivery, ...) 엔티티를 분류하고 개념적 모델링, 논리적 모델링을 진행하면서 몇 가지 궁금한 점이 있어서 질문드립니다. 현재 강의에서는 Order - OrderItem - Product 관계가 존재했고, 만약 Store와 Product 사이에 "무엇"을 등록한다 라는 관계가 존재한다면, Order - OrderItem - Product - Store 이렇게 관계가 형성될 것 같습니다. 질문 1. Order와 Store 관계 Order와 Store 사이에, "어디에서" 주문한다 라는 관계가 있다고 볼 수 있는지 궁금합니다. (비즈니스 적으로 의미가 있는지에 따라 관계 여부를 결정하는게 맞을까요?) 질문 2. 만약에 관계가 존재한다고 생각하면 Order와 Store를 직접적으로 관계를 맺어주는게 좋을지, 아니면 그래프 탐색을 통해 관계를 참조하는게 좋을 지 궁금합니다. 사실 Order - OrderItem - Product - Store 순으로 모두 Join 하면, 직접적인 연관관계를 맺지 않아도 원하는 데이터를 조회할 수 있을 것이라고 생각하는데요. 만약에 Order와 Store만으로 구성된 화면이 존재하거나, Store 정보를 바탕으로 Order를 필터링 해야한다면, Order에 Store의 식별자를 가지고 있으면 편하게 조회할 수 있을 것 같더라고요. 다만, 이렇게 되면 화면이나 Api에 의존적이게 모델링되는 것 같은데, 이러한 설계 방식이 괜찮은 방식인지 궁금합니다.
airtable 무료로 쓰고 있는데, 무료도 한계가 있어서 이것 저것 찾아보고 있는데, 반가운 소식이네요. 아직 beta여서 별 기능이 없지만, 더 기능이 추가 될꺼라 생각이 되네요. airtable 대신 사용을 해봤는데, 사용하는데 무리가 없네요. data table 노드가 생겨서 함 글을 남겨봅니다.
결제를 여러군데 하고 있는데 perplexity ai 까지 API를 결재해야는지 여쭤봅니다.perplexity ai 로 검색했을때 좋은 결과를 얻지 못한거 같아서요 n8n자동화 워드프레스 운영시 perplexity ai api를 반드시 결재해야 하는지 여쭤봅니다. 그게 아니면 14강은 건너뛰어도 되는지 여쭤봅니다.
strings .\dumps\1640.dmp > strings_1640.log 명령어를 입력했을 때 오래 걸린다고 하셨는데 저는 아무 반 ༔없이 프롬프트가 바로 뜹니다. Notepad++에도 파일을 올려보면 강의와 같은 내용이 안 뜨고 무슨 라이선스.. 이런게 뜨는데 뭐가 문제일까요?
안녕하세요. rebase 단원(이전 강의)의 설명을 들으면서, rebase 란 fast-forward merge 를 수행할 수 있게끔 commit history 를 flatten 해 주는 작업으로 이해했는데요. rebase 과정에서도 conflict 가 발생하고, 이것을 처리해줄 필요가 있다면, 그냥 3-way merge 에서 conflict 를 처리하는 것과 근본적인 차이가 있을까요? 제 생각으로는 rebase 과정에서는 branch 에서 떨어져 나간 commit 들이 생기고, 3-way merge 에서는 기존 commit 들이 병합된 branch 안에 들어있다, 는 차이 정도밖에 없는 것 같은데요. 굳이 3-way merge 말고 rebase 를 사용해야 할 필요가 있을까요?
안녕하세요~ 강의 잘 보고 있습니다. withCheckedContinuation 에서 resume 호출에 대해 질문이 있습니다. 11강의 12:56 쯤에서 ' withCheckedContinuation 에서는 resume 을 두번 호출해도, runtime 에서 알아서 두번째 resume 되는걸 체크해서 크래시가 발생하지 않게 해준다고 공식문서에서 나와있다. 즉, 안전하다' 라고 설명을 해주시는데요 (12강에서도 Checked 는 안전하다고 나와있구요), 제가 확인을 해보았을때는 withCheckedContinuation 에서도 resume 을 두번 호출하면 런타임 에러가 발생하는 것을 확인했습니다. 다만 CheckedContinuation과 UnsafeContinuation 의 케이스별 에러 로그 / 콘솔 로그가 조금 달랐습니다. 애플 문서에서는 checked continuation 만이 오용(misuse)에 대한 detect 및 diagnose 를 제공한다고 되어있는데요, 이를 통해 제가 유추할 수 있는건 withCheckedContinuation 은 런타임에 "안전" 하다기 보다는, resume 을 잘못 사용했을때 좀 더 자세한 에러 로그(여러번 호출시) 및 콘솔 로그(미호출시)를 통해 개발자가 resume 을 한번만 올바르게 호출할 수 있도록 도와주는 역할을 한다는 것이었습니다. 혹시 withCheckContinuation 에 대해 강의해서 설명해주신 "안전" 의 의미와, "두번째 resume 되는걸 체크해서 크래시가 발생하지 않게 해준다" 의 문서 레퍼런스를 알 수 있을까요? 참고로 체크한 코드는 다음과 같습니다 func fetchGreeting(completion: @escaping (Result<String, MyError>) -> Void) { completion(.success("hello")) } enum MyError: Error { case bye } func asyncFetchGreeting() async throws -> String { let greeting = try await withCheckedThrowingContinuation { continuation in fetchGreeting { greeting in continuation.resume(with: greeting) // 📍 resume 호출부 } } return greeting } Task { do { let greeting = try await asyncFetchGreeting() } catch { } } 감사합니다.
찾아보니 아래처럼 나옵니다. ``` fetchResults() 는 Querydsl 5.x부터 deprecated(더 이상 권장되지 않음) 처리되었습니다. fetchResults() 는 count 쿼리 와 content 쿼리 를 내부적으로 두 번 실행 해서 결과를 가져옵니다. 즉, 전체 개수( total count )와 페이징된 결과( results )를 한 번에 반환하려고 했는데, JPA 환경에서는 count 쿼리 최적화 문제 SQL이 복잡해질 경우 성능 저하 문제 Querydsl 5.x 이후로는 직접 count 쿼리와 content 쿼리를 분리 해서 호출하는 방식을 권장합니다. ```
