궁금한게 있습니다. 생각보다 많은 선배개발자님들은 강의에서 말하는 절차지향프로그래밍을 하고 있습니다. 심지어 우리나라에 네카라쿠배라고 하는 회사에서도 비슷한 장면이 자주 목격되는데요.  그분들이 잘못되었다고 생각하지는 않지만, 어떻게 그렇게 코딩을 하게 된건지 그 뒷배경이 궁금합니다..! 저는 개발한지 이제 7년밖에 되지 않아, 더 과거에 대한 이야기를 알지 못합니다. 조영호님께서는 오랜시간 연구하면서 왜 그렇게 된 것인지 알고 계시지 않을까 싶어 여쭤봐요!

담당자님 안녕하세요!혹시 수업 노트에서 제공되는 예제 코드로 개선된 코드가 아닌 개선이 필요한 코드를 올려주실 수 있을까요?강의 7:30 부근에서 "여러분이 직접 결차적인 방식으로 작성된 코드 전체를 도메인의 구조에 맞춰서 변경..." 하면서 수업 노트로 제공된 예제 코드를 개선하는 과제를 암시하고 있습니다.단, 예제 코드는 이미 개선된 코드를 제공하고 있습니다.그래서, 의도된 바와는 다르게 개선된 코드를 더 개선하려고 노력하였습니다.읽어주셔서 감사드립니다!

안녕하세요. 강의 유익하게 잘 듣고 있습니다.자동차의 여러 가지 세션들을 소개해주셨는데 제가 제대로 이해한 것이 맞는지 궁금해서 글을 올리게 되었습니다. 자동차의 대표적인 진단세션은 Default session, Programmming session, Extended session 이렇게 3가지가 있고, 그중 Extended session은 Default session과 Programming session보다 좀 더 다양한 진단서비스가 가능한 세션이다.↑ 이렇게 이해했는데 맞나요? 그리고 강의엔 없던 내용이지만 한 가지 더 궁금한 게 있는데, DTC(Diagnostic Trouble Code)를 읽는 진단서비스는 Default session에서도 가능한가요? (DTC가 복잡한 진단서비스인지 간단한 진단서비스인지 잘 모르겠습니다^^;)

응집도의 높고 낮음이, [동일 시점에 동일한 속도] 여부에 따라 정해진다고 하셨는데,이때,[시점]은 '할인 정책의 종류나 금액 계산 방법이 변경' 과 같이, [특정 요구사항의 변경이 일어날 때] 를 의미하는것으로 이해했는데, [속도] 는 무엇을 의미하는지 잘 이해가 되지 않아서 질문 남겨보아요.

안녕하세요. 첫 강의를 수강했는데 JTAG port와 Debug port 두 용어가 같은 맥락인 것 같은데 어떤 차이가 있는지 궁금합니다. Debug port가 좀 더 포괄적인 개념인가요? (Debug port의 한 종류로서 JTAG 포트가 존재하는 것인가요?)

안녕하세요. 좋은 강의 찍어주셔서 진심으로 감사합니다. 한 마디 한 마디 이해하려고 하며 배우고 있습니다. 3-1 강의 11분 쯤에 '행동을 결정하고 객체를 나중에 선택하라는 원칙'이 객체를 선택하기 전에 요청을 결정하기 때문에 코드를 수정하지 않고도 협력하는 객체를 교체할 수 있게 해준다고 말씀하신 부분을 좀 더 설명해주실 수 있을까요 ??calculateDiscount 행동을 먼저 정하고 이 행동을 하기에 적합한 객체를 선택한다고 말씀해주신 앞부분 내용은 잘 이해했는데, '객체를 선택하기 전에 요청을 결정하기 때문에 코드를 수정하지 않고도 협력하는 객체를 교체할 수 있게 해준다' 이 부분에 대한 이해가 잘 안 갑니다.여담이지만 <객체지향과 사실과 오해> 도 잘 읽었습니다. <오브젝트> 책이 두꺼워서 망설이고 있었는데 강의를 내주셔서 감사합니다.

안녕하세요. 신입으로 취업준비하면서 공부중인데 응용을 못하던 차에 너무 필요한 강의를 만난것 같습니다! 제가 궁금한 부분은'객체 협력(런타임)에서 클래스 구조(컴파일타임)의 순서로 진행'에서 런타임과 컴파일타임이 어떻게 연결되는 개념인지 입니다. 제가 해당 챕터에서 이 내용을 이해하기로는 아래와 같습니다. 변경에 용이하기 위해 과한 의존성을 피하여 파급효과를 줄여야 한다는점.이를 위해서 통제된 문맥을 갖는것이 중요하고, 이에 따라 행동을 먼저 결정하고 상태를 결정한다는 점.그런데 순서상 객체안의 데이터는 객체가 정의되어야 객체의 데이터도 결정되기 때문에 필연적으로 순서상 객체의 협력을 먼저 고려하여 객체를 드러낸 뒤, 클래스를 설계해야 한다는 의미로 이해했습니다. 단순히 런타임은 실행시점, 컴파일타임은 컴파일 시점인 것이라고 생각하고 있는데, 어떤 맥락에서 이런 표현들이 연결되는 것인지 잘 모르겠습니다. 사실 다른 책에서도 갑자기 '런타임 시점에', '컴파일 시점에'라는 말들이 가끔 나오는데 매번 잘 이해했다고 생각하다가 저런 말들이 갑자기 나오면 불편해졌던 기억이 납니다. ㅠ 제가 잘못 강의를 이해한것인지, 아니면 해당 맥락에서 반드시 이해해야 할 기본 배경지식을 놓치고 있는것은 아닌지 모르겠습니다.

안녕하세요. 강의 잘 보고 있습니다. 🙂 두 가지 정도 수정해주시면 좋을만한 내용이 보여서, 문의 남겨봅니다. 1. 속도 조절기 PDF 21페이지, 속도 조절기(Rate Limiter) 강의 영상 기준 18분 이후-> HTTP 420 -> HTTP 429가 좀 더 맞는 것 같습니다!물론 420을 쓰는 사례가 있다는 것도 알고 있습니다~ 2. 웹 크롤러(Web Crawler) 강의 중 9분 ~ 9분 40초 쯤-> 강의 영상에서 해당 부분은 편집해주시는 것이 조금 더 낫지 않을까 싶습니다 🙂   확인 부탁드려요!좋은 강의 만들어주셔서 감사합니다.

다른 질문 답변에 DAO에 인터페이스를 사용하는 이유DAO에 인터페이스를 사용하는 이유는 다양한 DAO 구현체를 제공하기 위해서가 아니라 의존성을 끊기 위해서입니다.이렇게 답변을 하신게 있는데, 그렇다면 DAO에 인터테이스를 사용하는 주된이유는 SOLID원칙 중 DIP원칙을 통해서 의존성을 끊기 위해서라고 이해를 했습니다그런데 OCP와 DIP가 의미적인 부분에서 일맥상통하는 부분이 있는 것 같기도 하고,, 좀 구별하기가 어려운 것 같습니다추가적으로 같이 달아주신 블로그 링크도 확인했지만 여전히 모호한 것 같습니다둘다 인터페이스를 통해서 구현을 할 수 있지만 OCP는 다양한 DAO구현체를 제공하기 위한 것에 초점을 맞춘 것이고, DIP는 의존성을 끊기 위한 것에 초점을 맞춘 것이라고 이해하면 될까요흠,, 명확하게 이해하진 못한 것 같습니다 어떻게 이해해야될까요..?!

먼저, 강의 너무 잘 들었습니다. 너무 좋은 내용을 압축적으로 전달 받았습니다. 감사합니다. 강의를 듣고 나니, 두 가지가 인상깊었는데요.객체를 사용한다고 해서 객체 지향이 아니구나. 객체를 사용하더라도 절차지향적으로 설계할 수 있다.객체지향 설계를 제대로 하다보면, DDD를 자연스레 실천하게 된다. (DDD 패턴을 적용하는 것은 아님) 실제 사용 중인 코드를 보니, Service 객체가 비즈니스 로직을 왕창 들고 있더라구요. 클래스의 인스턴스도 객체보다는 데이터에 가까웠습니다. 데이터만 담고 있고, 데이터를 조작하는 로직은 모두 Service가 들고 있었어요. "그동안 절차지향적으로 코드를 작성했던거구나!"를 알게 되었습니다. 그러면서 문득, 강사님 블로그에서 봤던 글이 생각났는데요. [도메인 주도 설계의 본질](https://eternity-object.tistory.com/26)이라는 글의 마지막 부분입니다.아마 모든 소프트웨어 애플리케이션의 95%는 “DDD를 적용하기에 적절하지 않은” 범주에 속할 것이다. 대부분의 소프트웨어는 근본적으로 데이터 중심적이다. 여기서 말씀하시는 "데이터 중심적"이라는 것이, 데이터를 먼저 설계하고 프로세스를 나중에 설계하는 절차지향적 설계를 말씀하신 것인지가 궁금했습니다. 제가 이해한 바가 맞을까요? 적고보니 질문을 위한 사족(?)이 길었군요. 답변 주시면 감사하겠습니다 :) 

안녕하세요 좋은 강의 감사합니다! ReservationService에서 xxDAO를 인터페이스로 선언한 부분에서 질문드립니다. 아래와 같이 여러 persistence 클래스를 같이 사용하는 경우 결합도를 낮추려면 xxxDAO 구현체 내부에 jpaRepository, querydslRepository, jdbcRepository를 주입받는 것이 좋을까요?(이렇게 하면 xxxDAO를 인터페이스로 선언할 필요가 있나 고민도 됩니다)public class xxxService { JpaRepository jpaRepository; QueryDslRepository queryDslRepository; JdbcRepository jdbcRepository; } 

안녕하세요 강사님, 강의 잘 듣고 있습니다.수업자료를 매 강의마다 따로 받아야 하는데요. 혹시 수업자료를 다 모아서 압축파일로 한번에 내려받게 해주시면 수강생들이 좀 더 편하지 않을까 요청드립니다. 태블릿에 한번에 넣어서 보기 편하도록 말이죠. 강의 잘 보겠습니다. 감사합니다!!

도메인 객체를 jpa로 바로 매핑해서 사용도메인 객체는 순수하게 유지하고, jpa용 객체로 변환을 해서 사용2가지 방식에 대해 다 장단점이 있고,실제로도 두 방식 다 많이 사용되는 걸로 알고 있는데 영호님의 생각과 어떤 걸 선호하시는지 궁금합니다.

안녕하세요. 항상 좋은 강의 감사드립니다. 혹시 오토사 강의 출시 예정일을 대략적으로나마 알 수 있을까요~? 감사합니다. 

우선 정말 좋은 강의 제작해 주셔서 감사합니다!채팅 시스템 관련 강의 약 19분 경에 나온 데이터 모델 설계에 대해 궁금한 점이 있습니다.DynamoDB와 같은 key-value 저장소를 기반으로 1:1 채팅을 구현할 때, pk(key)를 message_id 로 설정해주셨는데요.사용자가 로그인하여 사용자 식별자(user_id)를 얻었을 때, 이 user_id를 이용해 어떻게 관련 message_id들을 조회할 수 있을지 머릿속으로 잘 그려지지 않는데 혹시 이에 대해 좀 더 설명해주시면 정말 감사하겠습니다!!제 생각으로는 GSI를 활용해 user_id를 별도의 키로 설정하거나, 다른 형태의 추가 키가 필요할 것 같아보여서요아니면 혹시 이 key-value 저장소가 임시 저장 용도로만 사용되는 건가요?

아 이건 처음부터 수업 내용에 대한 질문이나 의문이라기보다 그 예제를 보다 현실적으로 확장했을 때 이런 부분을 어떻게 생각하시는지 정도의 질문입니다. 수업의 용이성을 위해 구현된 코드에 의문이나 불만은 없습니다 ^^정책이 여러 개의 컨디션을 소유하고 그 중 하나만 걸리면 할인 금액을 계산하게 되어있습니다.이게 약간 논리적으로 혼란한데 할인이 일어나는 이유는 컨디션에 걸렸기 때문으로 결국 진짜 할인 이유는 소유한 컨디션 중 하나입니다.결국 걸린 컨디션에 따라 할인 금액이 달라질 것 같이 생겼는데, 정책은 고정된 방법으로 할인가를 계산하고 있습니다.이것이 잘못되었다고 생각하지는 않는데, 이런 논리의 흐름이라면 역시 영화가 다수의 정책을 소유해야 하지 않나 싶어서요.

상영은 영화에게 요금계산을 맡기고영화는 다시 정책에게 요금 계산을 맡기죠정책은 다시 컨디션에게 할인 여부를 판정하게 하고컨디션은 다시 상영에게 협조를 구합니다.대표적으로 4번의 상황에서 나오는 코드가 시퀀스판정입니다.헌데 이 코드의 구조를 보면 말이 컨디션이 스크린과 협조한거지 상영의 속성을 그대로 까서 얻은 것과 진배 없습니다.더 나아가 컨디션은 상영의 속성 변화나 애당초 주어진 상영의 지식 정도에 큰 영향을 받아 구현됩니다. 상영의 지식이 적으면 구현할 수 있는 컨디션도 좁은 범위의 가능성을 갖게 되며 상영이 추가적인 정보가 확장된다면 컨디션도 더 많은 구조로 확장할 수 있게 됩니다. 즉 이 둘은 완전히는 아니지만 변화율이 상당히 긴밀하다 할 수 있습니다.현실적으로는 마케팅팀의 입김에 의해 컨디션을 추가하려다보니 상영에 정보가 충분치 않아 추가하게 될 가능성이 높아 보입니다.또한 이런면에서 상영은 역할이나 책임을 수행한다기보다 컨디션 입장에서는 그냥 데이터클래스로 보이는 수준이라고 생각됩니다. 이미 컨디션의 이름이 상영의 속성을 평가하겠다는 뉘앙스를 강하게 풍기고 있습니다.제 생각에는 이러한 이유로 컨디션과 상영이 충분히 디커플링 되어야 한다고 생각합니다.그래야 할인조건을 만드는 변화율과 상영의 변화율을 분리할 수 있기 때문입니다.이 디커플링으로 가장 적절한 장소는 정책의 calculateDiscount메소드의 for루프라 생각됩니다.interface ConditionInfo{ int getSequence() ZonedDateTime getStartTime() int getMinAge() int getRunningTimeMinute() } ... for(DiscountCondition each:conditions){ ConditionInfo info = new ScreenInfo(Screen); if(each.isSatisfiedBy(info)){ ...게다가 이 설계는 일견 의존성 흐름이 단방향처럼 보이지만 결국 정책이 상영을 알고 상영은 영화를 알게 되면서 다시 영화가 정책을 알게 되는 순환 의존성의 구조로 귀결됩니다. 물론 영화가 정책에 의존하는 부분은 단지 소유밖에 없으니 그나마 나은 편이지만, 정책이 컨디션에게 상영을 던져주면서 부탁하면 컨디션이 상영에 정보가 충분치 않은 경우 상영이 다시 영화에 추가 정보를 만들게 하는 순환구조가 일어납니다.사실 정책이 getDiscountAmount하는 과정도 말이 좋아 상영에게 받은거지 그건 결국 완전히 영화의 가격에 의존하는 로직입니다. 즉 사실상 정책과 영화의 단방향 의존성은 순환의존성으로 깨져버린 상태라 디자인상 그냥 정책 생성시 영화를 넣어주는게 더 유지보수가 편한 거 아니냐? 라는 생각도 들었습니다.전체 도메인에서 정책 내의 컨디션이 핵심비지니스 로직이라고 판단되는 바, 이 부분을 더 추상화할 필요는 충분히 있다 생각됩니다.

7분 30초 정도에 끝나는 내용일텐데 중간에 영상이 한번더 붙여넣기 된 건지 그 이후에 같은 내용의 영상이 다시 나옵니다.

고객이 구매하는건 상영인데 왜 영화가 가격을 들고 있을까요. 상식적이라면 상영이 가격을 들고 있을거 같아요.

안녕하세요 🙂 현재 계속 업로드 계획중이라 하셨는데 섹션 몇까지 예정되어있는지, 총 강의 시간은 어느정도가 될지 대략적으로 알 수 있을까요? 좋은 강의 만들어주셔서 감사합니다~!