우선 강의 너무 잘듣고 있습니다 감사합니다 저는 6년차 백엔드 개발자인데요요즘 미들급도 전부 코테를 보더라구요 카카오 신입 코테 기준이 골드4라고 말씀주셨는데경력직도 비슷할까요?

매 섹션마다 코랩 파일로 주시는 연습문제의 답은 어디서 확인할 수 있을까요?

안녕하세요, 헤이밥님! 강의 잘 듣고 있습니다!다름이 아니라 제가 다음 주 토요일에 코딩테스트 시험이 있는데요, 짧은 기간 내에 핵심만 공부를 하려고 할 때 강의 목차 기준으로 어떻게 학습하는 것이 효율적일지 여쭤봅니다! 당연히 모든 강의를 순차적으로 듣는 것이 가장 효율적인 방법이지만 현실적으로 시간이 부족하다고 생각해서요! 참고로 코딩테스트 기업은 네이버입니다! 감사합니다!

안녕하세요. 항상 좋은 강의 잘 듣고 있습니다. 다름이 아니라, 강의 및 강의 자료에 누락된 부분이 있는 것 같아 글 남깁니다.[물리적 모델링 - 실습] 파트에서 테이블 정의서 및 DDL 스크립트를 작성하는 부분에 order_item 테이블이 order_id와 product_id를 각각 외래키로 들고 있는데, 앞선 강의에서 설명해주신 바에 따르면, 주문 항목 데이터 저장 시, 특정 주문에 대한 특정 상품 하나가 여러 번 중복으로 저장되는 걸 방지하기 위해, (order_id, product_id)에 UNIQUE 제약조건을 만들어야 된다라고 하셨는데, 그 부분이 빠진 것 같습니다.감사합니다.

현재 강의에서는 Inventory table을 따로 분리해두었습니다.그런데 Inventory Table을 분리한 이유에 대해 말씀해 주실 때, 분리하는 게 좋다고만 말씀해주신 것 같아서 설명이 부족하다는 생각이 들었습니다. Inventory가 재고라는 의미를 가지는 것으로 알고 있어서 items table에 있는 수량을 Inventory로 옮기는 것이 더 옳은 설계가 아닌가라는 생각이 들었습니다.물론 지금 강사님께서 설명해주신 구조도 맞다고 보지만, 그 구조를 유지한다면 현재 Inventory table에 유의미한 칼럼이 없기 때문에 Inventory table이 없어야 하지 않나라는 생각을 했습니다. 그리고 재고가 자주 바뀌는 상황이 발생한다고 한다면 오히려 Inventory table에 재고를 넘겨줘야한다고 생각을 하는데요. 왜냐하면 Items table에 재고 칼럼이 있다면 재고가 바뀌는 순간에는 Items table의 데이터를 수정할 수 없게 됩니다. 그러면 관리자가 Item을 수정하려고 할 때, 재고가 많이 바뀌는 상황에는 그만큼 수정 쿼리가 대기를 하게 될 것이라고 생각하는데요. (물론 이 정도까지의 문제는 생기지 않을 것이라고 생각합니다.) 또한 이 글에서 강사님께서 말씀해주신 유형별 재고 관리 정책 부분은 Inventory가 재고라는 성격을 나타낸다는 점에서 Inventory table에서 관리할 것 같고, 트래픽 증가 시 성능 문제가 생긴다면 여기서 또 테이블 분리를 시도하거나 레디스 같은 memory DB를 생각해볼 수 있을 것 같습니다. 그래서 질문은현재 재고 칼럼의 위치를 어디에 두는 게 맞는지, 트래픽 증가의 성능 문제가 있다면 오히려 Inventory 테이블로 넘겨주는 게 맞는게 아닌지유형별 재고 관리 정책이 필요한 경우에 강사님께서 생각하시는 확장성 있는 구조는 무엇인지가 궁금합니다.  혹시 제가 잘못 알고 있거나 잘못 이해한 부분이 있다면 같이 짚어주시면 감사하겠습니다!

안녕하세요 백엔드 개발자를 희망하고 있는 학생입니다.유저별 포인트 같은 정합성이 중요한 데이터로 로그를 따로 관리 해야한다고 말씀 해 주셨는데 이런 경우(배치 도구를 스프링 배치를 사용할 경우에) 로그 테이블을 따로 만들어서 관리 해주는게 나중에 자소서 쓸 때도 도움이 되나요?   

다른 강의에 첨부된 자료들은 모두 pdf인 것 같은데, 이 강의에 첨부된 자료는 PPT이네요.

안녕하세요!강의를 통해 많은 인사이트를 얻었습니다. 좋은 강의 제공해주셔서 감사합니다. 강의를 수강하는 과정에서 궁금한 점이 생겨 질문 남깁니다. 시스템 디자인 단계에서 응답 시간(P95/P99)이나 TPS 같은 성능 목표를 설정할 때,인스턴스 스펙이나 인프라 제약도 함께 고려해야 하는지가 궁금합니다. 특히 학생이나 개인 프로젝트의 경우 프리티어처럼 제한된 리소스를 사용하는 일이 많은데,이런 환경에서는 인프라 제약을 기준으로 현실적인 목표치를 설정하는 것이 맞는지,아니면 인프라 스펙을 별도로 고려하지 않고 일반적인 목표값을 그대로 설정하는 것이 더 바람직한지 조언 부탁드립니다. 감사합니다!

안녕하세요!제공해주신 1강 목표문제 풀이 영상은 없나요?1강 목표문제 풀이에서는 제공해주신 목표문제가 아니라 다른 문제를 풀이해주셔서요..!연습문제&목표문제로 제공해주신 목표문제에 대한 풀이가 보고싶은데 강의 영상은 따로 없어서, 누락인가 해서 질문 드려요!

차량 보안 관련해서 면접 보게 되었는데 아예 지식이 없는 상태입니다. 어떤 순서로 들으면 좋을까요?

영호님 안녕하세요! 이번에는 설계원칙편의 6-1장 강의를 듣던 중, 궁금한 부분이 생겨 질문 드립니다~!! 디미터 법칙을 만족시키기 위해 Game 클래스의 showRoom() 메서드 내부의 구현을 리팩토링 하는 과정에서 player.currentRoom()메서드를 통해 Room 객체에 접근하여 name과 description 정보를 반환받도록 하는 부분이 있었습니다. Q. 혹시 showRoom() 메서드 내부에서 player로부터 Room 객체를 반환 받아 Game객체가 사용하는 것이 아닌, Room에 대한 정보를 Room객체로부터 바로 반환 받도록 하는 것은 어떠신지 궁금합니다!  예를 들어서 Room에 대한 정보를 Room이 책임지도록 하였을 때public class Player { private WorldMap worldMap; private Position position; ... public String currentRoom() { return worldMap.roomAt(position).getRoomInfo(); // 디미터 법칙 준수 } } public class Room { private Position position; private String name; private String description; ... public String getRoomInfo() { return String.format("현재 위치는 %s 입니다. %s\n", name, description); } } Room에 층수 정보와 같이 무언가 추가되는 상황이 발생하더라도 Game에서는 코드를 수정할 필요가 없이 Room 객체 내부에서만 변경하면 될 것 같아보였습니다! 🤔

통상의 Presentation - Business - Data Access에서 구현 계층이 추가됐고 구현 계층은 동일 레이어 간 상호 참조를 가능하게 한 부분이 있으니 비즈니스 계층은 상호 참조를 금지하는 것은 이해가 됐습니다. 기존에 제가 짜던 코드는 비즈니스 계층 + 구현 계층이었으니 비즈니스 계층을 나누는 기준이 기존 방식과 달라져야 그게 가능하겠다 까지는 생각이 들었고 기존에는 도메인으로 서비스를 만들었다면비즈니스 흐름 별로 서비스를 만들어야 되겠다 라고 생각이 들었습니다. 어떻게 보면 서비스가 중복되고 세분화 된다고 볼 수도 있을거 같지만 단순 기능의 나열이 아니라 비즈니스와 일치하게 코드가 짜지겠다 생각이 드네요 여기까지 제가 말한 게 어떤지 하고 간단한 예시도 알려주시면 정리하는데 도움이 될 것 같습니다.다른 강의도 잘 듣고 있습니다~ 감사합니다 아래 질문을 보고 추가한 내용입니다.https://inf.run/QjDgU리뷰와 포인트 서비스에 대한 예시였고 제 생각에는 비즈니스는 리뷰 작성이고리뷰 작성에 따른 포인트 관리는 구현 단계에서 연결하면 되겠다 라고 생각이 들었습니다.뭔가 더 생각해야 할 것들이 있을지 궁금하네요

professor_bcnf, enrollment_bcnf로 테이블을 분리하는 과정에서 질문이 있습니다.  이전에 이름과 같은 자연키는 기본키로 두면 안된다고 들었는데 현재는 professor_bcnf에서 professor_name이 기본키로 있습니다. 이런 경우에는 문제가 딱히 생기지 않나요?

영호님 안녕하세요!!  [6-5. 설계 평가하기] 강의를 듣던 중 궁금한 부분이 생겨 질문을 드리게 되었습니다! 컴파일 타임 결합에서 런타임 결합으로 변경하는 과정에서 Movie 클래스의 calculateFee메서드와 DiscountPolicy 추상클래스의 getDiscountAmount 메서드가 Screening 객체에 의존하게 되는데- Movie 클래스의 경우에는 Screening 객체를 직접 사용하는 것이 아닌 DiscountPolicy에 전달만 하고 있으며, - DiscountPolicy를 상속받은 AmountDiscountPolicy 클래스의 경우에는 아예 Screening 객체를 사용하지 않고 있는 상황입니다!Q. 혹시 이렇게 직접적으로 사용하지 않더라도, 메서드 파라미터로 정의해도 괜찮은 것인가요??

위 구조에서 테스트를 작성 시 의존성을 주입하는 방법에 대해 고민해보았습니다.테스트 코드 작성 시 Data Access Layer의 의존성에 대해서 구현 코드에서 사용하는 의존성을 그대로 사용하는지, 아니면 뒤에 나오는 모듈 개념을 활용하여 테스트 전용 모듈을 사용해서 의존성을 주입하면 괜찮을지 질문드립니다!

제미니 선생님, 안녕하세요. 이해가 잘 되도록 설명해주셔서 감사드립니다.다름이 아니라 비즈니스 레이어에서도 동일 레이어 간 참조 금지 규칙이 적용되는 것으로 보입니다.담당자들이 특정 업무 A, B, C를 진행할 때는 공통적으로 특정 업무 절차 D를 따라야 하는 상황을 생각해보았습니다. 가장 단순하게 구현하면 비즈니스 레이어에 A -> D, B -> D, C -> D의 의 존성이 생길 것 같은데, 이를 어떤 식으로 해결하면 좋을지와 그 이유가 궁금했습니다.감사합니다!

영호님 안녕하세요 😊 이번에는 2-4강을 듣던 도중 강의 자료와 관련된 질문을 드려요 Q. DiscountCondition을 책임지는 로직을 DiscountPolicy로 이동할 때,DiscountPolicy 클래스에 있는 findDiscountCondition()메서드의 접근 제어자가 private으로 되어있는 부분은 public으로 변경하고ReservationService 클래스의 reserveScreening() 메서드에서 policy.findDiscountCondition(screening, conditions);으로 생각하면 될까요?! 2-4 강의자료 page 10 (강의 02:29) 2-4 강의자료 page 11 (강의 02:42)

영호님 안녕하세요! 강의를 보다가 궁금한 부분이 생겨 질문 드려요~Q1. 현재 구조에서 "영화 관람료"라는 객체를 추가하여 상영 객체가 의존하는 방식도 괜찮을까요?Q2. 추가적으로 위의 방식이 나쁘지 않은 방식이라면, 할인 정책을 영화가 아닌 상영과 협력하도록 해도 괜찮을까요?질문들이 강의에서 가르쳐주시려는 포인트에서 벗어나는 질문이지만,,, 현실과 조금 더 밀접하게 연결지어 생각을 하다보니 이런 방식을 생각해보게 되었습니다

Engineering Landsacpe 설명하실때 그림을 잘 그려주셨는데, 해당 그림은 어떤 툴을 사용하신 건지 문의드립니다.감사합니다.

안녕하세요 강사님, 강의 잘 보고 있습니다. 이동 로직을 정리하다가 보호(가드) 로직 중복에 대해 질문드립니다.현재 구조에서 Game.tryMove()에서 player.canMove(dir)로 먼저 확인하고, Player.move(dir) 내부에서도 canMove(dir)를 다시 확인하여 막습니다.즉, 이동 가능 여부 판정이 두 번 수행됩니다.// Game private void tryMove(Direction dir) { if (player.canMove(dir)) { // 1차 player.move(dir); // 내부의 2차 showRoom(); } else showBlocked(); } // Player public void move(Direction dir) { if (!canMove(dir)) throw new IllegalArgumentException(); this.position = this.position.shift(dir); } 두 번의 가드가 필요한 이유가 있을까요? SRP/TDA 관점에서는 Game의 판정을 제거하고 player.tryMove(dir)만 호출해 결과만 처리하는 패턴이 더 적절한지, 혹은 move()만 두고 예외로 제어하는 방식을 권장하시는지 궁금합니다.