안녕하세요. 좋은 강의 감사합니다. 덕분에 객체지향에 대한 이해가 많이 정리되었습니다.3-2 강의를 보다 메서드 크기 관련해서 궁금한 점이 있어 질문드립니다.콘솔 입력 의존성(12:17) 부분에서 입력을 분리하는 예시로 아래와 같이 nextLine() 호출을 별도 메서드로 추출하신 것으로 이해했습니다.private String input(){ return Scanner.nextLine(); }그런데 이 관점이라면, 입력 “수집(I/O)” 뿐 아니라 “입력 파싱(문법)”도 별도의 책임으로 분리해야 하는 것 아닌지 고민이 됩니다. 예를 들어:private String[] inputParsing(String input){ return input().toLowerCase().trim().split("\\s+"); }강사님의 강의 및 "객체지향의 사실과 오해" 책을 읽고 난 뒤, SRP의 책임을 ‘하나의 변경 이유’로 보았습니다.위의 콘솔 입력(nextLine)을 분리한 건 입력 장치 변경이라는 액터에 대한 책임 분리로 이해했습니다.그렇다면 입력 파싱(toLowerCase/trim/split)은 명령 문법 변경이라는 또 다른 액터에 대한 책임이므로, 이 역시 별도로 분리해야 SRP를 완전히 지키는 게 아닐까요? 물론 이렇게까지 분리하면 가독성이 떨어질 수 있고, 실제로는 변경 가능성도 낮아 “가치가 작은 분리”로 느껴지기도 합니다. 강사님의 의견이 궁금합니다!+ 외에도 추상화 수준을 맞추기 위한 메서드 추출(9:25) 강의 자료에isRunning 함수의 반환이 void로 되어있으나 실제 내부에선 running == true를 반환합니다. github 코드 상에는 해당 함수가 없어보입니다.

"실전 개념적 모델링 - 시작" 파트를 들으면서 궁금한 점이 있어 질문드립니다. 주문, 결제 엔티티의 경우, 주문은 '결제'까지 포함하는 비즈니스 트랜잭션 단위라 하였는데, 왜 두개의 엔티티로 분류해야하는지 궁금합니다.현재 요구사항에서는 하나로 합쳐도 문제가 없는건가요?

안녕하세요, Tinder 설계 강의 내용에 궁금한 점이 생겨 질문 드립니다. Matching Service와 Cassandra 사용에 대한 질문입니다.Matching Service의 MQ와 /swipe의 matching 응답값 강의에서는 REST API는 지연이 발생할 수 있으므로 MQ를 사용했다고 말씀하셨습니다. 이때 API 명세에 있는 matching 값의 해석이 헷갈립니다. matching은 swipe 시점에서 자신이 상대와 매칭되었는지 알 수 있는 값이라고 생각되는데, 그러면 동기 처리가 필요한 것 아닌가 생각이 듭니다. 즉 Cassandra에서 inverse swipe이 존재하는지를 확인한 뒤에야 API 응답을 보낼 수 있는 것 아닌가요?Cassandra의 필요성RDB 조회만으로 inverse swipe 여부를 파악할 수 있을 것 같습니다. 그러면 Cassandra는 캐싱 용도로 사용한 것이라고 보아야 하나요? 원래 설계에서 Cassandra가 자연스럽게 도입된 이유가 궁금합니다.Cassandra - RDB 동기화 여부swipe 기록을 RDB와 Cassandra에도 모두 저장할 때, 일시적 오류 등으로 한쪽에만 저장될 수도 있을 것 같은데, 이런 상황에 대비해 RDB와 Cassandra 간 동기화가 필요한지 궁금합니다.감사합니다.

안녕하세요 강의 듣고 복습을 하고 있는 수강생입니다. 영화예매 시스템의 데이터베이스 설계의 관점에서 봤을때, 처음 생각나는 도메인은 영화, 예매 두개의 도메인을 고민했습니다. 하지만 영화, 예매는 N:M 관계로 판단이 됐으며,다대다 관계를 해소하기 위하여 상영이라는 도메인이 나왔나? 라고 생각했습니다. 이 관점으로 상영이라는 도메인을 고려하였는지 궁금합니다. 그게 아니라면 상영이라는 도메인이 나올 수 있었던 과정에 대해 설명해주시면 감사드리겠습니다. 

실무에서도 복수 항목에 대해서 원자성을 고려해 테이블을 분리하는지 궁금합니다. 예를 들어, 카드 정보라는 테이블이 있을 때, 혜택이라는 컬럼에는 '캐시백', '쿠폰 할인' 이런 식으로 복수의 데이터가 들어가게 되는데, 그럼 따로 카드 혜택이라는 하위 테이블을 만들어서 관리하나요? 이런 복수 항목이 늘어날 때마다 테이블을 하나씩 만들어야 하는지... 테이블 구조가 복잡해지는 느낌이 들어 질문드립니다.

역할 및 발생 시점에 따른 엔티티 분류를 설명하는 파트에서 궁금한 점이 있습니다. 지난 강의까지 주문 엔티티는 사건 발생의 결과물(즉, 주문 이력)이 기록되는 엔티티라고 이해했었는데요."엔티티 분류1" 강의에서는 기본, 중심, 행위 엔티티로 나눠서 생각해볼 수 있다고 했습니다. 그때 중심 엔티티에서도 예시가 주문으로 나와있고, 행위 엔티티에서도 주문 이력으로 나와 있는데, 이 두 개가 다른 경우인가요? 중심 엔티티의 주문과 행위 엔티티의 차이가 무엇인가요? 감사합니다.

안녕하세요. 사이드 프로젝트를 설계하다 보면 테이블의 키를 어떻게 가져갈지 고민을 많이 하게됩니다. 영한님의 말씀대로 대부분 대체키로 만들지만 숫자 대체키의 경우 1부터 순차적으로 올라가게 대부분 구조가 만들어지게 됩니다. 이게 혹여나 보안에 우려가 있을까 염려됩니다. 안전하게 UUID로 대체키를 주면 강의에서 말씀해 주신것 처럼 성능 부분에서 trade off가 있어서 이 방법도 고민됩니다. 예를 들어서 회원이라면 회원 정보를 조회하는 GET API에 회원ID(숫자 대리키, pk) 를 보내면 해당 유저 정보를 조회하게 되는데 숫자를 임의로 바꿔서 다른 유저 정보를 조회하는 이런 부분에서 혹여나 보안 관점에서 우려가 있지 않을까? 생각을 갖게 됩니다. 그러다 보니 두 가지 방안이 떠오르는데 실무에서 추천해주실 방안이 있는지 궁금합니다. 대체키(숫자)를 사용하되 애플리케이션에서 validation을 확실하게 설정pk는 대체키(숫자, pk)를 하되 db에서 join, 외래키로만 사용하고 외부로 나갈 때는 다른 대체키(UUID, unique)로만 보내는 방식영한님을 기다리며... 답변에 미리 감사드립니다.

시스템 디자인 관련 질문서버가 PreSigned URL 을 발급하면 클라이언트가 URL 을 기반으로 Blob Storage에 다이렉트로 파일을 업로드 한 것으로 이해했습니다.클라이언트가 업로드를 하는데 서버가 현재 청크의 진행상황을 탐지하여 Key-Value 에 업데이트 하는 메커니즘이 궁금합니다.가령 서버가 Blob Storage 를 주기적으로 찔러 업데이트하는 과정일지 궁금합니다. 그림 상으로는 서버가 청크 진행상황을 알기위해서 추가적인 메커니즘이 있을까 생각이 들어서요.

유니크 제약조건에 대해 질문드립니다. 예를 들어 핸드폰 번호당 계정을 하나만 가질 수 있어서 핸드폰 컬럼을 유니크제약을 걸었습니다.특정 회원이 탈퇴할 때 하드 딜리트가 아니라 소프트 딜리트를 하는 정책일 경우, 탈퇴 했던 유저가 다시 가입하게되면 어떻게 해줘야할까요.? 그럼 결국 유니크 제약을 디비에서 없애고, 애플리케이션 단에서 제어를 해야할까요?

정규화와 정규형을 생각할 때는 자연키를 사용한다는 것을 가정해야할까요?예를 들어,회원 테이블을 회원id (대리키), 아이디(자연키), 비밀번호, 이메일 속성으로 정의할 때, 회원id 는 아이디를 결정하고 (회원id -> 아이디), 아이디는 비밀번호, 이메일을 결정하므로 (아이디 -> 비밀번호, 아이디 -> 이메일) 이행함수 종속이 발생하는 것처럼 보입니다. 이처럼 정규화와 정규형을 생각할 때에는 대리키 개념을 배제하고, 자연키를 기준으로 생각해야할까요?

안녕하세요. 강의 잘 듣고 있습니다.Secure Access 요약부분을 듣다가 궁금한점이 생기게 되어서 질문 남깁니다. 상위 ECU에서 하위 ECU에게 SEED 값을 요청했고, 하위 ECU가 상위 ECU에게 랜덤한 SEED값을 보내준다고 하셨습니다. 그럼 SEED 값을 받은 상위 ECU는 받은 'SEED값'을 대칭키 알고리즘을 사용하여 암호화되어 전달된다라고 이해했는데 맞게 이해한걸까요? 그러면 암호화된 SEED값이 하위 ECU에게 보내지는건데, 그 과정에서 "ClientSendKey"라고 되어있는건 그 암호화된 데이터가 Key가 되어서 전달되는건가요? 아니면 암호화된 데이터 자체를 key라고 지칭하는건가요? 혼동이 되어 질문드립니다!감사합니다.

set(DATA_LIST ${CMAKE_CURRENT_SOURCE_DIR}/directory0/file.txt ${CMAKE_CURRENT_SOURCE_DIR}/directory0/directory ${CMAKE_CURRENT_SOURCE_DIR}/directory0/symlink.txt file.txt directory0/directory directory0/symlink.txt ) foreach(DATA ${DATA_LIST}) if(IS_DIRECTORY ${DATA}) message(STATUS "${DATA} is a directory") endif() endforeach() 왜 directory0/directory 는 IS_DIRECTORY 에서 참으로 판단되지 않나요?

Control statement 26:45 에 "^[a-z]{3}.txt$" 가 아닌 "^[a-z]3\\.txt$"가 맞는 것 같습니다.

결제와 주문, 배송과 주문 관계까 1대1인데 결제, 배송 쪽 관계 표시가 선택적1로 되어 있는데 잘못된거 아닌가요'?

사이드프로젝트로 백엔드 시스템을 개발할때 어떤 순서로 해야되나요? 데이터베이스 설계를 먼저 한 뒤에 코드작성을 시작해야되나요? 그리고 만약 개발과정에서 처음 설계한 데이터베이스 규칙에 위반되는 코드가 나온다면 어떻게 해야하나요?

안녕하세요 영한님. 강의를 들으면서 파편화된 정보를 정리하고 있어 너무 즐겁게 강의를 듣고 있습니다.  그런데 AI 퀴즈를 풀던 중 해당 퀴즈에서 뭔가 의아함을 느껴 질문드립니다.   물론 A를 토대로, 외래 키 컬럼에 NULL을 허용함으로써 선택적 참여를 구현할 수 있다는 것까지는 이해할 수 있겠습니다.   다만 [별도 참여 테이블 생성]이 위에 말씀 주신 member를 생성하는 것이라면 B가 더 적합한 선택지라는 생각이 듭니다.  혹시 [별도 참여 테이블 생성]이라는 선택지는 team / member 외의 테이블을 하나 더 만드는 것을 의미했던 걸까요? 비롯해서 해설에 있는 [맞을까요?]라는 질문이 적절하지 않게 느껴지는데요.  인프런으로 문의드릴까 하다가, 문제에 대한 질문을 드리는 것은 이쪽이 맞을 것 같아서 QnA로 질문드립니다!

프론트엔드 개발자와 함께 작업을 하게 된다면 용어 사전같은 프로젝드 관련 파일들을 공유 하는지 궁금 합니다.

안녕하세요 영한님!!강의 복습에 있어 설계 강의는 어떻게 강의 복습을 해야하는지 너무 뜬구름 잡는 기분이라 조언을 얻고자 합니다.설계라는 게 아직은 멀리 있는 과정이라 생각이 들어서 그런지 더욱 어려운것 같습니다조언 부탁드려요!

안녕하세요.좋은 강의 감사합니다.사소하지만 더 나은 품질을 위해 제보 드립니다. 6-4. 캡슐화 강의 = 7분19초SOLID 원칙 개방-폐쇄 원칙 약어 수정 필요LSP > OCP개방-폐쇄 원칙의 약어가 이전 설명의 리스코프 치환 원칙의 약어로 잘 못 표기된것으로 보입니다.항상 좋은 강의 감사합니다.

6-4 캡슐화에서 서브타입이 슈퍼타입을 대체할 수 있는 것이 SOLID 원칙 중 리스코프 치환원칙이라고 하셨는데 제가 알고있는 리스코프 치환원칙은 서브타입은 슈퍼타입을 대체 할 수 있어야 하고 슈퍼타입에서의 행위를 서브타입에서도 동일한 결과값이 예상될 수 있어야한다로 알고있습니다!e.g) Collection의 add 메소드는 어떤 서브타입이여도 "추가"한다는 행위가 되어야한다"서브타입이 슈퍼타입을 대체할 수 있다" 도 리스코프치환원칙의 특징이 맞지만 해당 원칙이 전하려는 주된 내용은 행위의 같은 예상 결과값으로 보여서요! 어떻게 생각하시는 지 궁금합니다!