안녕하세요!현대적인 설계에서는 대부분 자연 키가 아닌 대리 키를 기본 키로 사용하는 것이 권장된다고 하셨는데요.그렇다면 혹시 자연 키를 기본 키로 사용해도 괜찮은 예외적인 상황이 있을까요?예를 들어, 변경 가능성이 거의 없는 코드성 데이터나 표준화된 식별자(예: ISO 코드, 통화 코드 등) 같은 경우에도 무조건 대리 키를 추가하는 것이 좋은지, 아니면 자연 키를 PK로 두어도 실무적으로 문제가 없는 기준이 있는지 궁금합니다. 감사합니다 ☺︎

데이터베이스의 컬럼명과 애플리케이션 코드의 일치성을 가져가는게 가독성면에서 좋다고 생각하는데..모든 컬럼이 앱 코드와 일치되어야하는건 또 아닐거같아서요. e.g) 앱 코드에서는 필드를 두개로 나눌수도 있지만 데이터베이스 컬럼에서는 하나의 컬럼으로 가져가는 경우도 있나요?

안녕하세요. 좋은 강의 감사합니다.값 객체에 대한 내용을 듣고 궁금했던 점이 있었는데, 섹션 4 퀴즈를 풀면서 해소되는 동시에 새로운 질문이 생겼습니다.값 객체를 사용하는 메소드를 과도하게 호출하여 OOM(Out of Memory)이 발생할 것으로 예상되는 경우, 이를 어떻게 회피할 수 있는지 궁금합니다.아직 강의를 전부 듣지 않아서 이후에 나올 내용일 수도 있겠지만, 지금 드는 생각으로는 Map을 이용해 내부적으로 캐시를 구현하여 메모리 사용량을 줄이는 방법이 떠오르는데, 이 접근법이 맞을지 궁금합니다.

안녕하세요! 영호님. 강의 잘 듣고 있습니다.  현실적으로 DB 스키마가 이미 정해져 있거나, 기존 데이터를 마이그레이션해야 해서 새롭게 설계하기 어려운 경우, 또는 DBA가 별도로 관리하는 환경에서는 책임주도 설계를 적용하기가 쉽지 않을 것 같습니다. 이런 상황에서도 객체지향적인 설계를 현실적으로 적용할 수 있는 방법이 있을까요?(DAO를 중간 계층으로 두면 어느 정도 해결될까요? 아니면 도메인 레이어와 퍼시스턴스 레이어는 분리된 영역이니 크게 상관없을까요? 반대로, 두 레이어가 지나치게 달라지면 오히려 유지보수가 더 어려워지지는 않을까 하는 걱정도 듭니다.)그리고, 책임주도 설계가 이론적으로는 유지보수에 강하다고 하지만, 실제로는 아직 구조가 다소 복잡하게 느껴져서 오히려 유지보수성을 해칠 수도 있지 않을까 합니다. 이런 복잡함은 설계 패턴에 익숙해지면 자연스럽게 해소될까요?감사합니다!

안녕하세요!덕분에 아키텍처에 대한 큰 그림을 그려보며 강의를 듣고 있습니다. MSA 전환 시점 관련해서 질문 드립니다.모놀리식 아키텍처에서 MSA로 전환하는 적절한 시점은 어떤 기준으로 잡는게 좋을까요?물론 상황마다 다르겠지만, 강사님은 어떤 기준을 가장 중요하게 생각하시는지 궁금합니다.예를 들어, Scale-out 한계, 빌드&배포 시간 증가, 혹은 서비스 크기와 복잡성 같은 요소들.. 이 있을 것 같은데 제가 미처 생각 못한 부분이 있다면 덧붙여 답변 부탁드립니다.감사합니다!

안녕하세요. 메서드를 설계할 때 궁금한 점이 있어서 질문드려요.예를들어 메서드를 설계할 때 (Long customerId, Long screeningId, Integer audienceCount) 파라미터에 이렇게 ID 식별자를 넣어줘야는지 혹은 객체를 넣어줘야하는지를 설계할 때는 어떤 점을 판단하는 것이 좋을까요?

안녕하세요. 좋은 강의를 통해 값진 지식을 얻어갔습니다. 감사합니다.다름이 아니라 완강 이후 "좋은 도메인 모델은 어떻게 만드는 것인가?" 라는 의문이 들었습니다.강의를 통해 도메인 모델과 변경의 관점에서 설계를 평가하는 방법과 책임을 부여하는 패턴들을 통해 개발자의 변경에 유연한 코드를 만드는 실마리는 얻었지만 한편으로는 이러한 부분들은 문맥을 제공하는 도메인 모델이 잘 정의되어있을 때, 빛이 발하는 것이 아닌가 생각이 들었습니다.사실 현업에서 도메인 모델을 따로 정의하고 의식하면서 개발을 해본 경험이 없기 때문에 어떻게 하는 것이 좋을지 잘 모르겠습니다. 따라서 아래의 세부 의문점에 대해 답변해주실 수 있으면 감사하겠습니다.도메인 모델은 개발 프로세스 중 어느 시점에 정의하는 것이 좋은지?도메인 모델을 정의하는 것은 개발자가 주도적으로 이끄는 것인지 아니면 기획자와 같은 다른 팀원들과 함께 만들어 나가는 것인지?만들어진 도메인 모델을 토대로 설계 및 개발을 진행하다 도메인 모델을 변경해야만 하는 순간이 있는지?좋은 도메인 모델을 만들었는지 평가해볼만한 방법들이 있는지?

실무에서 단일 컬럼 PK만으로 행을 식별할 수 없는 경우가 있습니다.예를 들어 영화 예매 시스템에서 ‘상영회차’와 ‘좌석’ 정보를 조합해야만 특정 예매 내역을 정확히 구분할 수 있을 때가 있죠.이런 경우 복합키를 사용하게 되는데, 실제 설계에서는 어떤 방식으로 복합키를 구성하고, 단일 PK와 비교했을 때 어떤 장단점이 있는지 경험 기반으로 설명해주실 수 있나요?

강의 중 교과서 공부라는 내용은 나오는데, 좀 추상적으로 느껴져서요.적절한 범위 내에서만 공부하는 게 좋을 것 같은데, 추천하는 범위, 단원, 종류 등 간단하게 알 수 있을까요?

정규 테이블과 JSON 컬럼을 함께 사용할 때, 정규화를 유지할지 JSON으로 비정규화할지 어떤 기준으로 결정하나요?

제 1,2,3 정규형 강의를 들었을 때, 정규형은 종속 분리의 연속이다라는 생각이 들어서 질문 남깁니다. 앞에서부터 '제1 정규형 만족 -> 제2 정규형 만족 -> 제3 정규형 만족' 이라는 과정이 종속 분리가 차근차근 진행되는거죠? 제가 생각한 것처럼 이해하면 될까요?

안녕하세요, 강사님. 강의를 들으면서 데이터베이스 설계와 모델링의 중요성을 많이 느끼고 있습니다.문득 ‘데이터베이스 설계를 잘한다’ 혹은 ‘데이터 모델링을 잘한다’는 게 어떤 의미인지 궁금해졌습니다.설계 과정에는 개념적, 논리적, 물리적 모델링 등 여러 단계가 있고, 각 단계마다 좋은 설계의 기준이 조금씩 다를 것 같은데요.실무에서는 이런 기준을 어떤 방식으로 판단하시나요?만약 같은 요구사항을 모델링했을 때 한쪽은 유지보수성이 높고 다른 쪽은 성능이 좋은 경우, 어떤 관점에서 우선순위를 정하시는지도 궁금합니다. 좋은 강의 제작해주셔서 감사합니다!

안녕하세요 이번 강의 정말 잘 들었습니다!강의에서는 주로 MySQL을 사용했는데 현업에서도 PostgreSQL대신 MySQL을 많이 사용하는지 궁금합니다. RDB를 선택할 때 기준같은게 있는지도 궁금합니다!

스키마 명세서, 요구사항 명세없이 유지보수, 개발된 프로젝트의 경우 스키마 명세서를 나중에라도 추가해서 관리하는게 훨씬 좋을까요?/./

DAP 데이터 설계 자격증 현업에서 유용하거나 인정해주는 자격증인가요

물리적 모델링에서 PK의 타입을 선택할 때 대부분 BIGINT를 사용하고 용량 차이도 크지않다는 강의가 매우 좋았습니다.그런데 논리적 모델링에서 PK로 UUID도 사용한다고 들었는데 UUID는 128바이트로 16바이트로 정수 PK보다 2배 더 크고 식별하기도 힘들것이라고 생각되는데 사용한 경험이 있으실까요?아니면 어떠한 상황에서 장점이 있는지 궁금합니다.

안녕하세요 강사님! 강의 잘 듣고 있습니다.실제 서비스 환경에서 로드 밸런서를 두는 시점(예: 트래픽 기준이나 서버 수 기준)을 어떻게 판단하시는지 궁금합니다.단순히 서버 부하율이 높아졌을 때 적용하는 건지, 아니면 아키텍처 설계 초기에 미리 구성하는 경우가 더 일반적인지도 궁금합니다.

안녕하세요.  객체지향 설계에서, 객체의 상태를 getter로 직접 꺼내서 사용하기보다 객체에 메시지를 보내 처리하라는 원칙을 따르려고 합니다.그런데 만약 특정 로직이 코드 전체에서 단 한 번만 사용되는 경우에도, 이 원칙을 지키기 위해 객체 내부에 새로운 메서드를 구현하는 것이 올바른 방법일까요? 아니면 이런 예외적인 경우에는 실용성을 고려해 getter를 사용하는 것이 더 나을까요?

AI 도구가 발전한 지금, 개발자로서 차별화되는 실력은 어떤 부분에서 나타나나요?

pdf의 17~18 페이지, 강의의 4:54Reader를 reader 패키지에서 game 패키지로 이동시켜 reader 패키지가 game 패키지를 의존하게 만들 수 있다고 하셨는데 패키지란게 Java의 기능인가요? 그렇다면 C++에 대응될 만한 기능이 있을까요?