위 구조에서 테스트를 작성 시 의존성을 주입하는 방법에 대해 고민해보았습니다.테스트 코드 작성 시 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()만 두고 예외로 제어하는 방식을 권장하시는지 궁금합니다. 

안녕하세요. 좋은 강의 감사합니다. 덕분에 객체지향에 대한 이해가 많이 정리되었습니다.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로 되어 있는데 잘못된거 아닌가요'?