안녕하세요!좋은 강의 제작해주셔서 감사합니다.토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 파트2 강의는 언제쯤 나오는지 알 수 있을까요??

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요.  BDD 설명하시면서 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준을 권장한다고 하셨는데요  작성한 테스트를 따로 문서화 하기도 하시는지 궁금합니다!

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요.  단위테스트할때 항상 궁금했던 점이단순한 CRUD도 테스트코드를 구현해주는 게 맞는걸까요?JPA 기능을 그대로 적는? 느낌이 나서 굳이 필요한 테스트코드인가 하는 생각이 항상 드는데 왜 구현했는지에 대한 시나리오를 @DisplayName 적곤 하지만 뭔가 불필요하다는 생각이 가끔 들기도 하는데 다 적는 게 맞는거겠죠??

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예[질문 내용]여기에 질문 내용을 남겨주세요. 대부분을 jpa로 작성하고(jpql, QueryDSL), 극 소수의 안되는 것들에만 JDBC Templates, MyBatis를 이용하는 것으로 이해했습니다. 1) 그렇다면 가급적 Native Query는 사용을 지양하는게 좋을까요? Native Query를 사용해야할 정도라면 사실 JDBC Templates나 MyBatis를 이용하는게 나을테니까요. 2) 만약 그렇다면 MyBatis 등을 처리하기 위한 패키지를 따로 구분해서 처리를 하게 되나요? 이 경우에 .flush()를 처리하기 위해서 entityManager 인스턴스도 가져와서 따로 해줘야할 것 같은데, 구조가 조금 복잡해지지 않을까? 걱정 됩니다.    

일단 제가 배운대로면 결합도를 낮추는 것이 좋은 코드라고 배웠는데, 왜 그렇게 만드셨는지가 궁금합니다!

강의에서는 H2 인메모리 DB를 이용해 테스트를 진행하셨는데,실무에서는 테스트 환경에서 실제 MySQL이나 PostgreSQL 같은 실제 운영 DB와 동일한 컨테이너 기반 테스트 DB를 사용하는 경우도 많은 것 같습니다.실무에서는 인메모리 DB와 컨테이너 DB 중 어떤 상황에서 어떤 것을 선택하시는지, 선택 기준이나 장단점에 대해 조언을 받을수 있을까요?

8강 도메인 모델과 DDD 에서코드의 내용이 도메인에도 반영이 되어야 할 때도 있다고 하셨는데 예시를 들어 주실 수 있을까요?

강의 너무 재미있게 듣고 있습니다.도메인이라는 개념에 대해서 고민하다가 궁금한 사항이 생겨서 질문드립니다. "도메인 모델이 비즈니스 규칙을 모두 내포하면 응집도는 높아지지만, 복잡도도 함께 커집니다. 이때 어디까지를 도메인 모델에 포함시키는 게 적절할까요?"

Application Service에서는 흐름을 관리하고 (예를 들면 DB에서 데이터를 가져오는 등) Domain Service는 복잡한 비즈니스 로직을 처리하는 역할로 이해를 했는데 이해한 것이 맞을까요?

안녕하세요.  빈약한 도메인 모델에 관하여 질문이 있습니다.현재 개인적으로 진행하는 프로젝트에서 데이터 홀더 역할정도만 하는 빈약한 도메인 모델이 있습니다.repository에는 테이블의 상태 컬럼을 업데이트하는 메소드가 존재하는데 이를 도메인 모델 내부에 메소드를 만들어 업데이트하고 repository의 save를 통해 엔티티의 상태를 update하는 것이 강의에서 의도한 내용으로 이해했는데 맞을까요?추가로 이런 경우(비즈니스 로직이 복잡하지 않은)에 꼭 도메인 모델이 없어도 될지 궁금합니다. 

보통 실무에서는 deprecated된 사용할때 발견하면 그때 그때 찾아보나요? 아니면 항상 up-to-date하는 공부방법이 따로 있나요?

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]영속성 컨텍스트는 1차 캐시와 쓰기 지연 메모리가 있다고 강의에서 배웠습니다. 이 부분은 클라이언트단에서 관리하는 것인지 서버라면 어디에 저장되고 어떻게 관리되는 메모리인지 궁금합니다. (ex. 힙 등)

JPA entity와 도메인 모델을 분리하는 케이스에서 데이터 저장 기술이 바뀌는 경우 Spring Data를 사용하면 해당되지 않는다고 하셨는데 JPA에서 MyBatis로 변경하는 경우도 Spring Data로 커버가 가능한가요? 회사에서 JPA로 개발을 진행중인데 MyBatis로 마이그레이션을 해야할수도 있어서 질문드립니다.

안녕하세요. 코드에서 궁금한 점 질문드립니다.댓글 생성, 삭제 시에 게시글의 댓글 수 증감 로직이 아래 예시 코드처럼 CommentService에서 이루어지고 있는데 과한 책임이 아닌가 싶어서요. 실무에서는 어떻게 나누게 되는지 궁금합니다. public CommentResponse createComment(Long postId, CommentRequest request) { Post post = postRepository.findById(postId) .orElseThrow(() -> new IllegalArgumentException("게시글을 찾을 수 없습니다.")); Comment comment = Comment.builder() .content(request.content()) .postId(postId) .createdAt(LocalDateTime.now()) .updatedAt(LocalDateTime.now()) .build(); Comment newComment = commentRepository.save(comment); post.increaseCommentCount(); postRepository.save(post); return CommentResponse.from(newComment); }

강사님은 Classicist 쪽에 속하셔서 Service를 테스트할 경우 Repo도 포함한다고 하셨었는데 Controller에서는 MockMvc를 활용하셔서 따로 테스트한 것으로 알고 있습니다.컨트롤러 - 서비스, 레포지토리의 관계와 서비스 - 레포지토리의 관계에서 어떤 차이점 때문에 이렇게 구성하신 것인지 궁금합니다.

안녕하세요 토비님! 순수한 궁금증이 생겨서 질문 드립니다!아키텍처마다 장단점이 있다고 생각합니다. 프로젝트의 규모나 확장성 여부에 따라 어울리는 아키텍처가 다를 것 같은데요, 토비님은 현업에서 어떤 기준을 가장 중점적으로 두고 아키텍처를 선택하시는지 궁금합니다!

서비스를 소형 단위로 테스트하기 위해 Fake 클래스를 구현하는 실습을 진행하셨는데요.테스트 코드는 결국 구현된 기능이 정상적으로 동작하는지 검증하기 위한 것이라고 생각하는데요~그런데 H2 DB를 직접 띄워 테스트하는 방식과 비교했을 때, Fake 객체를 활용한 방식은 구현 방식에 따라 실제 동작과의 괴리가 생길 수도 있을 것 같은데, 이런 접근이 실제로 효과적인 테스트 방법인지 궁금합니다!

안녕하세요 토비님 🙃여러 데이터 접근 기술을 병행해야 하는 상황에서, 도메인 모델과 JPA 모델을 분리해서 관리하고 있습니다.이때 한 가지 궁금증이 생겼습니다.RDB 외의 데이터 접근 기술(예: Redis, MongoDB 등)을 고려하면 도메인 모델에서도 식별자(ID) 개념이 필요할 것 같은데, 이런 경우 도메인 객체가 ID를 직접 가지는 것이 괜찮을까요?만약 괜찮다면, 이는 RDB의 책임(시퀀스, AUTO_INCREMENT 등)에 위임하지 않고, 별도의 UUID나 Snowflake ID 등 도메인 차원의 식별자 생성 전략을 두어야 할 것 같은데 이런 방향성에 대해 어떻게 생각하시는지 궁금합니다.

강의를 NestJS로 적용해 따라가고 있습니다. 마지막 “ArchUnit을 이용한 아키텍처 테스트” 파트에서 Node/NestJS 환경에서는 어떤 방식으로 아키텍처 규칙을 테스트/검증하는 것이 좋은지 궁금합니다.자바에서는 ArchUnit으로 레이어 규칙, 패키지 의존성, 순환 참조 등을 명시적으로 검사할 수 있는데, Node 진영에서는 유사한 도구로 무엇을 추천하실까요? 제가 찾은 것은 “ts-arch”였고, 폴더/슬라이스 의존성, 사이클 검사를 지원하는 것으로 보입니다. 적용을 하다가 실패를 했는데, 다른 방법이 있다면 조언 부탁드립니다. 😭😭😭

안녕하세요, 강의 정말 잘보았습니다!!Part1을 전부 보고 나니까 part2가 언제쯤 나올지 궁금해서 질문남깁니다!