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

상영은 영화에게 요금계산을 맡기고영화는 다시 정책에게 요금 계산을 맡기죠정책은 다시 컨디션에게 할인 여부를 판정하게 하고컨디션은 다시 상영에게 협조를 구합니다.대표적으로 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초 정도에 끝나는 내용일텐데 중간에 영상이 한번더 붙여넣기 된 건지 그 이후에 같은 내용의 영상이 다시 나옵니다.

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

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

좋은강의 정말 감사드립니다!말씀하신 비즈니스 로직이 정말 보기에도 좋고 깔끔하다고 생각되서 저도 똑같이 구현해보고 싶다고 생각하는데요외부에서 주입받도록 분리한 로직들은 어느 레이어에 위치시켜야 하는지 궁금합니다. 아직 비즈니스 로직강의만 듣고 질문을 남겨서 혹시 뒷 강의에서 이에 대한 해답이 나온다면 답변해주지 않으셔도 괜찮습니다!감사합니다!

안녕하세요?ISP 강의를 잘 수강하고 있습니다.실무 경험이 많으신 분이 실무 사례를 통해 설명을 해주시니이해가 잘 되는 것 같습니다.강의를 들으면 이해는 되는데요... 막상 수행을 할려고 하니 힘드네요.그래서 책을 구입해서 보고 있으나, 책은 강의에서설명하시는 사례가 구체적으로 없어서 어려움이 있습니다.혹시 강의 사례를 공유해 주실 수는 없으신가요..

사용자, 이해관계자등 요구사항 도출은 설문/면단 활동을 통해 진행을 하는가요?

00:57넘어갈때 내용의 흐름이 끊긴거 같은데 확인 부탁드립니다.

강의 정말 잘 들었습니다! 비즈니스 로직에 대한 관점이 보다 명확해진 것 같아요. 한 가지 궁금한 점이 있습니다. "리팩터링 후의 메서드를 보면 입력받는 인자 targetStore 도 달라진 걸 볼 수 있죠" 와 같은 말씀을 해주셨는데여기서 새롭게 나오게된 개념인 targetStore, usePoint 인자들에 대한 처리가 리팩토링 전과 후 layer들 사이에서 어떻게 바뀌게 되는지 조금 더 자세한 내용이 궁금합니다! 리팩토링 전리팩토링 후 businessPay()메서드에서 pay 라는 비즈니스 로직을 처리하기 위해 요청에 대한 정보를 리팩터링 하기 전의 코드에서는 payRequest 로 presentation layer 에서 전달받고 있는 것 같아요. (저도 이렇게 하고 있었습니다)리팩터링 후의 코드에서는 targetStore, usePoint를 인자로 입력받고 있는걸 볼 수 있었어요. 여기서, 새롭게 나오게된 targetStore, usePoint 객체들을클라이언트로부터 전달되는 presentation layer 에서 바로 전달받는 것을 기대하셨는지아니면 리팩토링 전과 같이 payRequest 로 controller에서 전달 받은 뒤 다른 layer (business 혹은 presentation) 에서 dto 로 변경한 뒤 businessPay() 메서드를 호출하여 인자를 입력해주는 것을 기대하셨는지아니면 다른 방법으로 진행이 되는지  가 궁금합니다!

gtest/configurate_package.cmake 에 project(GTest...) 를 넣으면 GTest 가 설치되지도 않았는데 find_package() 에서 있는 걸로 처리되어서 install 이 안되고 있습니다.  혹시 제가 놓친 부분이 있을까요?  

안녕하세요. 제미니님 이번에도 좋은 강의를 제공해주셔서 감사합니다.모듈 분리에서 궁금한 내용이 있는데요. 제미니님이 제공해주신 PaymentAPI 와 DB 모듈을 별도로 했다고 했을 때 API 규격에 맞게 DB 모듈이 구현이 되어야 한다고 생각하고 있습니다. 즉, 해당 PaymentAPI 에서 제공하는 DB 접근에 대한 인터페이스를 DB 모듈이 구현하는 의존성 역전 원칙을 적용한 상황입니다.하지만, 이 상황에서 단방향 모듈 참조를 하게 된다면 DB 모듈은 PaymentAPI 가 제공하는 인터페이스의 유무를 알 수가 없게 되는데요. 저는 위 문제에 대한 해결방법으로 두 가지가 떠오릅니다.모듈 분리 시 API 모듈에 인터페이스를 만들고 DB 모듈 교체에 따른 새로운 구현체를 구현한다.(모듈 교체에 따라 이전 모듈에 대한 클래스 참조가 사라져 컴파일에러가 발생하게 되고 주석처리가 필요하다) 모듈 교체 시 이전 모듈에서 사용했던 인터페이스를 하위 모듈에서 똑같이 생성해주고 동일한 인터페이스를 참조하도록 하여 상위 모듈에는 변화를 주지 않는다. (변화가 최소화되지만 인터페이스가 많을 수록 구현도가 올라간다. 인터페이스를 동일하게 만들거라는 보장이 되어야 한다.)1번 코드paymentAPI { // implementation 'project:paymentDB' // implementation 'project:paymentDB2' interface CommandPort { fun save(command: PaymentCommand) } class PaymentDBImplV1 : CommandPort { override fun save(command: PaymentCommand) { paymentDB.saveV1(command); // paymentDB2 모듈 사용 시 주석 처리 } } class PaymentDBImplV2 : CommandPort { override fun save(command: PaymentCommand) { paymentDB2.saveV2(command); // paymentDB1 모듈 사용 시 주석 처리 } } } paymentDB { implementation 'A.DB' } paymentDB2 { implementation 'B.DB' }2번 코드paymentAPI { // implementation 'project:paymentDB' // implementation 'project:paymentDB2' class PaymentAPILogic(val paymentDB: CommandPort){ fun save(command: PaymentCommand) { paymentDB.save(command); // paymentDB2 모듈 사용 시 주석 처리 } } } paymentDB { implementation 'A.DB' interface CommandPort { fun save(command: PaymentCommand) } class PaymentCommandImpl : CommandPort { override fun save(command: PaymentCommand) { DB.save(command); } } } paymentDB2 { implementation 'B.DB' interface CommandPort { fun save(command: PaymentCommand) } class PaymentCommandImpl : CommandPort { override fun save(command: PaymentCommand) { DB.save(command); } } }간단하게 코드를 작성하면 위와 같은 형태가 될 것 같습니다.제미니님은 어떠한 방향으로 설계를 하시는지 혹은 제 질문에서 제가 잘 못 이해한 부분이 있어 이러한 방법으로 사고가 흘러가는지 말씀을 들어보고 싶습니다.마지막으로 유튜브 및 인프런에서 귀한 지식과 귀한 시간을 제공해주셔서 항상 감사합니다! 

안녕하세요. 강의를 보면서 따라 하고 싶은데 cmake 설치 및 버전, 파일 구조등에 대한 정보를 찾을 수 없어서 문의 드립니다.

프로젝트 시간이 부족한데요환경분석과 협황분석을 동시에 해도 되나요?

26분 45초에 다른 메시지를 보고 되었다고 오해하신거 같아요^[a-z]{3}.txt$abc.txt도 되지 않고 a3.txt도 되지 않는데 어떨때 True인가요?

single cluster 큰 장애 복구는 다른 클러스터로 우회한다고 하셨는데 single cluster는 클러스터가 1개 아닌가요 ??

안녕하세요. 우선 part 1 좋은 강의 감사합니다~part 2 강의 오픈은 언제쯤 되는지 궁금하고 무엇을 다룰 예정이신지도 궁금합니다.