강사님, MSA의 장애 격리에 대해 강의를 듣다가 궁금한 점이 생겨 질문드립니다. 제가 이해하기로는 모놀리식은 하나의 애플리케이션 안에 여러 도메인/서비스가 함께 구성되어 있고, MSA는 각 도메인별로 서비스를 분리하여 구성하는 것으로 알고 있습니다. 강의에서 MSA의 장점 중 하나로 장애 격리를 말씀해 주셨는데, 실제로는 한 서비스의 장애가 해당 서비스를 의존하고 있는 다른 서비스로 전파될 수도 있지 않을까 하는 생각이 들었습니다. 예를 들어 여러 서비스에서 회원 정보나 회원 상태를 검증하기 위해 회원 서비스에 요청을 보내야 하고, 회원 서비스의 검증 결과가 정상이어야만 해당 서비스를 이용할 수 있는 구조라고 가정하겠습니다. 이 경우 회원 서비스에 장애가 발생하면 회원 서비스에 의존하고 있는 여러 서비스에서도 요청 처리가 불가능해지기 때문에, 결국 장애가 다른 서비스로 전파되는 것처럼 보입니다. 그래서 제가 생각한 것은 MSA의 장애 격리가 '장애가 다른 서비스로 전혀 전파되지 않는다'는 의미보다는, 모놀리식에 비해 장애가 발생했을 때 영향을 받는 범위를 제한할 수 있다는 의미에 더 가깝지 않을까? 하는 것입니다. 예를 들어 모놀리식에서는 하나의 애플리케이션에 장애가 발생하면 전체 기능에 영향을 줄 수 있지만, MSA에서는 특정 서비스의 장애가 해당 서비스 및 이를 직접적으로 의존하는 서비스 정도로 영향 범위를 제한할 수 있다는 의미인지 궁금합니다. 그리고 실제 MSA 환경에서는 이러한 장애 전파를 막기 위해 Circuit Breaker, Timeout, Retry, Fallback, 비동기 메시징 등의 방법을 사용해서 장애 격리 수준을 높이는 것으로 이해하고 있는데, 제가 이해한 방향이 맞는지도 궁금합니다. 결국 MSA에서 말하는 장애 격리의 핵심이 '완전한 장애 격리'라기보다는 '장애 영향 범위를 줄이고 장애 전파를 제어할 수 있다'는 점에 있다고 이해하면 될까요?
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 20분 쯤 내용에서 실제 스키마의 기준이 DDL이라고 하더라도, 엔티티에 주요 제약과 인덱스를 함께 적어두면 코드만 봐도 DB 설계 의도를 파악할 수 있다는 장점 이 있다고 말씀하셨습니다. 해당 강의가 녹화된 날짜가 예전임을 감안했을 때, 현재까지도 유효한 말씀일까요? 물론 회사마다 규칙이 있고 다를 수 있다고 생각하고 또 요즘은 어떻게 설계하는지 궁금합니다.
안녕하세요! 강의를 열심히 듣다가 돌연 멀티 모듈이라는 주제로 생각하다가 질문을 남깁니다! 현재 강의에서는 application 레이어에서 repository를 가지고 있는데요! 멀티 모듈로 설계 시에도 동일하게 application 레이어에 repository를 가지는 게 일반적인가요? 검색을 하거나 하면 adapter에 persistence 쪽이나 infra 레이어 쪽에 가지고 있어야 한다는 내용이 보이는거 같아서요. 토비님께서는 어떻게 생각하시는지 궁금합니다! 또한, 보통 멀티 모듈로 프로젝트를 구성하실 때 어떤 방식으로 접근하시는지도 궁금합니다! 긴 글 읽어주셔서 감사합니다.
토비님 안녕하세요! 좋은 강의 만들어 주셔서 감사합니다. 객체지향 프로그래밍에서는 객체의 내부 구현이나 구조를 외부에서 직접 알 필요가 없도록 캡슐화하고, 객체의 행동을 통해 상호작용하는 것이 중요하다고 알고 있습니다. 기존 테스트에서는 Course 내부의 detail 객체에 직접 접근합니다. 이를 아래와 같이 수정해봤습니다. public class Course extends AbstractEntity { public LocalDateTime getPublishedAt() { return detail.getPublishedAt(); } } @Test void publish() { course.submitForReview(); course.publish(); assertThat(course.getStatus()).isEqualTo(CourseStatus.PUBLISHED); //assertThat(course.getDetail().getPublishedAt()).isNotNull(); assertThat(course.getPublishedAt()).isNotNull(); assertThatThrownBy(() -> course.publish()) .isInstanceOf(IllegalStateException.class); } 이러한 판단이 객체지향의 캡슐화, 정보 은닉 관점에서 올바른지 궁금합니다.
안녕하세요, FlushModeType.COMMIT 에 대한 부작용으로 기재하신 예시코드 관련 질문 드립니다. em.setFlushMode(FlushModeType.COMMIT); // 1. 회원 A 저장 em.persist(new Member("회원A")); // 2. 회원 조회 (JPQL) // 플러시가 안 일어남 -> DB에는 '회원A'가 없음 -> 조회 결과 0건 List<Member> list = em.createQuery("select m from Member m where m.name = '회원A'", Member.class) .getResultList(); // 결과: 방금 저장했는데 조회가 안 되는 미스터리 발생 😱 만약 Member 엔티티 클래스의 ID 생성 전략이 IDENTITY인 경우 em.persist(new Member("회원A")); 에 의해 INSERT 쿼리가 실행되므로, 그 아래 코드에서는 해당 데이터가 조회되지 않나요? 데이터 불일치 문제가 발생할 수 있으니 COMMIT 모드는 확실한 이해 하에 사용하라는 것은 확실히 이해했습니다! 다만 예시코드 보다가 급 궁금해져서요ㅎㅎ
안녕하세요. 토비님 DIP와 관련하여 질문이 있습니다. "course" 컴포넌트 <- "curriculum" 컴포넌트는 단방향 의존성을 가져야하기 때문에, CurriculumValidator.class를 DIP를 통해 course 패키지로 옮긴 것을 이해하였습니다. 하지만, CurriculumValidator에서 던지는 예외인 InvalidCurriculumException.class는 "curriculum" 도메인에 속해 있습니다. 이것은 결국 양방향 의존성을 가지게 되는 것 아닌가요? 만약, 양방향 의존성이 맞다면, CurriculumValidator 인터페이스는 ValidationException을 던지도록 선언하고, CurriculumValidator인터페이스 구현체인 "CurriculumModifyService.class"는 "InvalidCurriculumException" 을 catch해서 ValidationException을 던지도록 수정하는 방법도 괜찮을까요?
안녕하세요 토비님! 오랜만에 강의를 복습하다가 궁금한 점이 생겨 질문드립니다. 제가 헥사고날 아키텍처를 외부 서비스나 인프라 연동이 많은 시스템에서 주로 사용하는 구조 라고 이해하고 있었는데요. 강의에서는 비교적 작은 시스템에도 헥사고날 아키텍처를 적용하셔서, 제가 잘못 이해하고 있었던 건지 궁금합니다. 현재 작은 규모의 신규 프로젝트를 준비하고 있고, 도메인 모델 패턴과 풍부한 도메인 모델을 적용해보려고 합니다. 다만 외부 서비스 연동은 거의 없을 예정이라, 이런 경우에도 헥사고날 아키텍처를 적용하는 것이 적절한지, 아니면 오버엔지니어링이 될 수 있는지 판단이 잘 서지 않습니다. AI에게 물어봤을 때는 헥사고날 아키텍처 도입을 고려할 수 있는 기준으로 외부 연동의 수뿐만 아니라, 하나의 Port에 대해 구현체가 둘 이상 존재하거나 향후 교체 가능성이 있는지 도 이야기하더라고요. 강의에서 DDD와 헥사고날 아키텍처가 잘 맞는다고 설명해주셨는데, 결국 헥사고날 아키텍처를 선택할 때 외부 서비스 연동이 많은지 Port의 구현체가 여러 개이거나 교체 가능성이 있는지 도메인을 기술적인 의존성으로부터 분리할 필요가 큰지 같은 요소 중 무엇을 주요 기준으로 봐야 할까요? 작은 시스템이고 외부 연동도 거의 없다면 레이어드 아키텍처로 시작하는 것이 나은지, 아니면 풍부한 도메인 모델과 DDD를 적용한다는 이유만으로도 헥사고날 아키텍처를 선택할 충분한 이유가 있는지 궁금합니다.
평소에 인터페이스와 구현체를 만들때 테스트를 어디에 만드는게 맞을까란 고민을 했었는데, 마침 토비님이 강의에서 언급해주셔서 너무 반가웠는데요. 테스트는 인터페이스에 만들라는 말씀 잘 이해했습니다. 스펙을 테스트하기에 인터페이스를 대상으로 테스트를 만들어야하는것도 이해를 했는데요. 구현체가 2개 이상이 되면 어떻게 하시는지 궁금합니다. 각 구현체들이 스펙을 준수하는지 테스트 코드를 작성해야할텐데 인터페이스를 대상으로 테스트를 작성하면 구현체가 1개일땐 문제가 없는데 2개 이상일땐 좀 난감해지더라고요.
‘자바 ORM 표준 JPA 프로그래밍 - 기본편’ 강의가 올해 안으로 리뉴얼될 예정이라고 들었는데, 혹시 대략적인 리뉴얼 시기를 알 수 있을까요? 현재 강의를 바로 수강할지, 우선 프로젝트를 진행하면서 기다렸다가 리뉴얼된 강의를 수강할지 고민 중이라 문의드립니다. 감사합니다.
안녕하세요. 강의 잘 듣고있습니다. 오늘 수강한 "엔티티 식별자와 JPA 엔티티" 에서 JPA 엔티티로 만들었다고해서 달라진게 없다 라고 표현하셨는데요. 애노테이션을 붙여서 컴파일 단계의 의존성은 생겼지만 해당 클래스가 다른 기술적 종속이 생긴건 아니라고 말씀하신거에 질문이 있습니다. 일단 애노테이션을 붙인 것을 용인할 수 있다는건 이해했고, 저도 동의합니다. 그런데 JPA 엔티티가 됨으로써 해당 클래스는 final 로 만들 수 없고, 생성자도 기술적 요구사항에 의해 최소 protected 로 공개할 수 밖에 없는데요. 이번 강의에서도 기존 의도는 private 이었지만 기술을 도입함으로써 애노테이션을 붙이는 것 이상의 작업이 있었습니다(생성자의 접근 수준 변경). 정말 애노테이션만 붙이고 아무것도 하지 않았다면 납득할 수 있지만 애노테이션 외에 다른 변경이 발생했는데도 기술적 종속이 없다고 볼 수 있을까요? 이정도 수준의 변경과 의존은 트레이드오프로 용인할 수 있다고 생각하면 할수는 있지만 엄밀히 따진다면 객체 설계에 영향을 줬다고 생각하는데, 어떻게 생각하시는지 궁금합니다.
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (모름) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. 현재 시점(26.8) 에서 강의를 듣고 있는데요. pdf 을 보면, 시간 지남에 따라 assertEquals() 내용이 달라 지듯이, 그 동안 강의 에서 배운 assertj 의 assertThat().isEqualTo()나, 다른 방법 들이 있어서 어떤 것을 쓰는게 맞는지 몰라서 여쭈어 봅니다. 첫 번째는 assertEquals(), assertThat()이고 두번째는 assertThrows() , assertThatThrownBy() 입니다. 영한님 이라면 어떤 것들을 쓰실지 궁금합니다. 답변 부탁 드립니다.
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (모름) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. 스프링 트랜잭션 전파7 까지 지 강의를 보면서, 전 섹션 스프링 트랜잭션 의 이해 에서, 트랜잭션 aop 주의 상황 프록시 내부 호출1 -2 에서 만든, InternalCallV1Test ~ v2Test 가 개념적으로 비슷 하다 라는 느낌을 받았습니다. 이유가 객체가 자기 자신을 참조하고 있어서 내부 적용에 트랜잭션 작동이 안되서 , 새로이 만들어서 적용하는 모습 을 보고?, 말입니다. 영한님이 예제를 잘 만들어서 그런 건지는 몰라도 InternalCallV1test 가 현재 하고 잇는 BasicTxTest 랑 비슷하다고 생각도 듭니다. 이렇게 생각해도 되는지 알고 십습니다. 답변 부탁드립니다.
