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

querydsl이 쿼리를 코드로 작성하여 컴파일 시점에 오류를 감지할 수 있는게 가장 큰 장점인데 Spring JPA와 혼합하여 사용할떄 그 외에 장점이 또 있을까요 레거시 쿼리는 이미 사용되고 있어 이를 전환하기 위해 먼가 더 장점이 필요할 것 같아서요 아니면 레거시는 두고 신규 추가되는 부분만 Querydsl를 도입하는 식으로 가면 될까요?

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

fetch join 부분이 조금 어렵게 느껴져서, gpt에게 물어보며 공부했습니다.강의에서 fetch join으로 나온 중복 데이터를 DISTINCT 키워드를 이용해서 제거해주시는 부분을 보았는데, gpt가 다음과 같이 설명해주는 것을 보았습니다.DISTINCT 키워드가 SQL과 JPA 양쪽에서 다르게 동작하기 때문에 완전한 중복 제거가 보장되진 않습니다.이 말이 맞다면 현업에서는 이런 문제를 어떤 식으로 해결하는지 궁금합니다!

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

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

안녕하세요. 수업 내용과는 크게 관계가 없지만... 예외처리 관련 내용에 대한 질문을 드립니다. 스프링이 제공하는 표준 예외(IllegalArgumentException, IllegalStateException)와 비즈니스 로직을 표현하는 커스텀 예외(NotFoundUserException) 사이에서 표준 예외를 사용하는 경우와 커스텀 예외를 사용하는 경우에 대한 기준을 알 수 있을까요? 감사합니다.

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

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

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

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

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

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

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

안녕하세요 코틀린으로 현재 강의를 수강하고 있는 수강생입니다. 현재 자바로 작성된 코드를 보고 설명과 함께 어떤 이유로 이런 코드를 작성한 것인지 생각하며, 코틀린으로 이 개념을 적용하면 어떻게 작성할 수 있을지 DDD와 클린 아키텍처를 코틀린 문법 활용하여 구상하는 연습 중입니다. 현재 Member 도메인 코드 개선 강의에서 value class 적용하여 필드의 값이 바뀌는 문제(email자리에 nickname이 오더라도 같은 String이라 컴파일 에러가 안 남)를 해결하려 시도했습니다 package org.example.splearn.domain @JvmInline value class Email( val value: String, ) @JvmInline value class Nickname( val value: String, ) @JvmInline value class PasswordHash( val value: String, ) class Member private constructor( val email: Email, var nickname: Nickname, var passwordHash: PasswordHash, var status: MemberStatus, ) { fun activate() { check(status == MemberStatus.PENDING) { "회원이 PENDING 상태가 아닙니다" } this.status = MemberStatus.ACTIVATE } fun deactivate() { check(status == MemberStatus.ACTIVATE) { "회원이 ACTIVE 상태가 아닙니다" } this.status = MemberStatus.DEACTIVATED } fun verifyPassword( password: String, passwordEncoder: PasswordEncoder, ): Boolean = passwordEncoder.matches(password, this.passwordHash.value) fun changeNickname(nickname: String) { this.nickname = Nickname(nickname) } fun changePassword( password: String, passwordEncoder: PasswordEncoder, ) { this.passwordHash = PasswordHash(passwordEncoder.encode(password)) } fun isActive(): Boolean = this.status == MemberStatus.ACTIVATE companion object { fun create( memberCreateRequest: MemberCreateRequest, passwordEncoder: PasswordEncoder, ): Member = Member( email = memberCreateRequest.email, nickname = memberCreateRequest.nickname, passwordHash = PasswordHash( passwordEncoder.encode(memberCreateRequest.password.value), ), status = MemberStatus.PENDING, ) } } 강의대에서는 static 메소드인 of에서 MemberCreateRequest를 파라미터로 사옹하고 있습니다. 코틀린이라 companion object를 사용했구요 그러던 중 "헥사고날 아키텍처의 특성을 고려하면 의존성 외부 로직인 dto가 내부로 향해야 하고 따라서 도메인이 dto에 의존하는 것이 괜찮을까" 하는 의문이 들었습니다. companion object { fun create( email: Email, nickname: Nickname, password: String, passwordEncoder: PasswordEncoder, ): Member = Member( email = email, nickname = nickname, passwordHash = PasswordHash( passwordEncoder.encode(password), ), status = MemberStatus.PENDING, ) }그래서 코드를 수정해 보면 이런 식으로 수정해 볼 수 있을 것 같습니다. 이에 대해서 토비님 의견이 어떠신지 여쭙고 싶습니다

좋은 추석 보내고 계신가요?현재 코틀린으로 강의를 따라해 보고 있습니다. class Member private constructor( val email: String, var nickname: String, var passwordHash: String, var status: MemberStatus, ) { fun activate() { check(status == MemberStatus.PENDING) { "회원이 PENDING 상태가 아닙니다" } this.status = MemberStatus.ACTIVATE } fun deactivate() { check(status == MemberStatus.ACTIVATE) { "회원이 ACTIVE 상태가 아닙니다" } this.status = MemberStatus.DEACTIVATED } fun verifyPassword( password: String, passwordEncoder: PasswordEncoder, ): Boolean = passwordEncoder.matches(password, this.passwordHash) fun changeNickname(nickname: String) { this.nickname = nickname } fun changePassword(password: String) { this.passwordHash = password } companion object { fun create( email: String, nickname: String, password: String, passwordEncoder: PasswordEncoder, ): Member = Member( email, nickname, passwordEncoder.encode(password), MemberStatus.PENDING, ) } }이러한 식으로 작성하였는데 자바에서는 const로 선언한 객체나 변수가 아닌 이상 기본적으로 가변입니다. 그런데 코틀린에서는 val, var 키워드에 따라서 var로 선언해야 가변 타입이 됩니다. Member 도메인 모델 확장 챕터 수강하고 있는데 이 경우는 도메인에서 가변 속성을 미리 정의하고 해당 속성들을 var로 선언하는 것이 맞을지, 혹은 val을 통해 불변성을 확보하고 새 객체를 생성하여 변경을 처리하는 것이 적합할지 궁금합니다.코틀린에서 도메인 코드를 작성할 때 자바와 다른 문법&개념과 도메인 중심 설계가 종종 난해할 때가 있네요.

마지막 강의에서 진행한 헥사고날 아키텍처 테스트에서 저는 아래와 같이 에러가 발생하고 있는데 어떻게 수정을 해야 할까요? 소스 코드는 동일한 것 같은데... 무엇이 차이인지 모르겠어요 13:09:39.840 [Test worker] INFO com.tngtech.archunit.core.PluginLoader -- Detected Java version 17.0.12Architecture Violation [Priority: MEDIUM] - Rule 'Layered architecture considering all dependencies, consisting oflayer 'domain' ('com.inflearn.splearn.domain..')layer 'application' ('com.inflearn.splearn.application..')layer 'adapter' ('com.inflearn.splearn.adapter..')where layer 'domain' may only be accessed by layers ['application', 'adapter']where layer 'application' may only be accessed by layers ['adapter']where layer 'adapter' may not be accessed by any layer' was violated (1 times):Method <com.inflearn.splearn.SplearnTestConfiguration.passwordEncoder()> calls method <com.inflearn.splearn.domain.member.MemberFixture.createPasswordEncoder()> in (SplearnTestConfiguration.java:19)java.lang.AssertionError: Architecture Violation [Priority: MEDIUM] - Rule 'Layered architecture considering all dependencies, consisting oflayer 'domain' ('com.inflearn.splearn.domain..')layer 'application' ('com.inflearn.splearn.application..')layer 'adapter' ('com.inflearn.splearn.adapter..')where layer 'domain' may only be accessed by layers ['application', 'adapter']where layer 'application' may only be accessed by layers ['adapter']where layer 'adapter' may not be accessed by any layer' was violated (1 times):Method <com.inflearn.splearn.SplearnTestConfiguration.passwordEncoder()> calls method <com.inflearn.splearn.domain.member.MemberFixture.createPasswordEncoder()> in (SplearnTestConfiguration.java:19) at com.tngtech.archunit.lang.ArchRule$Assertions.assertNoViolation(ArchRule.java:94) at com.tngtech.archunit.lang.ArchRule$Assertions.check(ArchRule.java:86) at com.tngtech.archunit.library.Architectures$LayeredArchitecture.check(Architectures.java:347) at com.inflearn.splearn.HexagonalArchitectureTest.hexagonalArchitecture(HexagonalArchitectureTest.java:22) at java.base/java.lang.reflect.Method.invoke(Method.java:569) at com.tngtech.archunit.junit.internal.ReflectionUtils.invoke(ReflectionUtils.java:111) at com.tngtech.archunit.junit.internal.ReflectionUtils.invokeMethod(ReflectionUtils.java:103) at com.tngtech.archunit.junit.internal.ArchUnitTestDescriptor$ArchUnitMethodDescriptor.execute(ArchUnitTestDescriptor.java:203) at com.tngtech.archunit.junit.internal.ArchUnitTestDescriptor$ArchUnitMethodDescriptor.execute(ArchUnitTestDescriptor.java:173) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) 

안녕하세요 !! 도메인 모델의 값 객체 도입편에서 궁금한게 있습니다. 패스워드는 passwordEncoder를 의존하여 암호화와 매치 여부를 확인합니다. 이메일 vo는 검증 패턴이 member만 사용하는 것이 아니라 다른 곳에서도 사용할 수 있고 중복된 코드를 줄이기 위해서 변경하셨습니다. password도 이메일 vo처럼 매번 passwordEncoder를 주입받는 게 아니라 password VO를 만들어서 관리할 수 있을거같은데 패스워드는 의존성 주입으로 해결하게 되신 이유가 궁금합니다

안녕하세요 강사님 저번 테스트 코드 강의 부터 지금 리팩토링 강의까지 정말 잘 들었습니다!이번 강의에서는 record를 사용하지 않으셨는데 저는 보통 VO(Value Object)나 DTO를 만들 때 다음과 같은 이유로 record를 활용합니다불변성 보장보일러플레이트 감소그런데 프로젝트를 진행하다 보면 DTO나 VO에 로직이 점점 복잡해지고, 어느 순간 record로는 한계가 느껴져 class로 변환한 경험이 몇 번 있습니다. 이와 관련해 어떤 경우에 record를 사용하는 것이 좋을지 강사님의 의견이 궁금합니다! 

안녕하세요! 토비님.헷갈리는 개념이 하나 있어서 여쭤보고 싶습니다.바로 헥사고날 아키텍처에서 UseCase의 책임 범위인데요.우선 정답은 없다는 것은 알고 있습니다. 다만 Best Practice나 권장되는 방법이 있는지, 그리고 토비님의 고견이 궁금하여 질문드리게 되었습니다. 기능 단위로 UseCase 인터페이스 분리하기 vs 연관된 기능은 UseCase 인터페이스에 묶음으로 제공하기(메서드별로)입니다. 전자는 SRP가 매우 엄격하게 준수되고, 테스트 용이성, 개별 인터페이스별로 정책을 다르게 적용할 수 있다는 장점들이 있지만 과도하게 인터페이스화를 하다 보니 관리할 포인트가 많아져 복잡해진다는 게 단점인 것 같습니다. 후자는 SRP가 엄격하게 준수되지 않더라도, 관련된 기능을 응집도 있게 관리하기 때문에 테스트 용이성이 조금 떨어지고, 일관된 정책을 관리하거나 인터페이스가 비대해질 수도 있다는 단점이 있지만, 응집도 있게 관리하여 유지보수에는 편한 장점이 있는 것 같습니다. 코드를 예시로 보면 아래처럼 콘서트를 조회한다고 했을 때, 일반적으로 PK를 기반으로 조회하지만, 아래와 같이 콘서트명도 unique하고, 가수도 1개의 진행 중인 콘서트만 가지고 있을 수 있을 때 조회 조건이 Id, Name, ArtistName으로 분류될 수 있다고 예시를 들어보겠습니다.public interface GetConcertUseCase { ConcertResult findById(Long concertId); ConcertResult findByName(String name); ConcertResult findByArtistName(String ArtistName); ConcertResult findByIdWithSchedules(Long concertId); // Aggregate Member인 ConcertSchedule 목록 정보도 포함하여 조회 }위에처럼 구성하는 게 후자 방식이고 응집도가 높다고 생각합니다. 그런데 해당 방식은 유스케이스가 비대해질 수 있고, 단일 책임 원칙에서 벗어날 수 있다는 의견 때문에 조회 목적별로 유스케이스 분리하는 것을 권장하는 의견도 있습니다. (전자 방식)public class GetConcertByIdUseCase { ... } public class GetConcertByNameUseCase { ... } public class GetConcertByArtistUseCase { ... } public class GetConcertByIdWithSchedulesUseCase { ... } 정답은 없어서 프로젝트 규모나, 각자의 스타일, 기능 분석에 의해 정해지겠다만, 보편적으로 이런 경우 어떻게 접근하는 게 Best Practice인지 감이 잡히질 않아 질문드리게 되었습니다.