draw.io에서 도메인 모델을 설명해주시는 부분에 대해서 질문드립니다.도표의 다른 선들은 모두 화살표가 없는데, 수강은 회원과 강의 모델로 화살표가 있어서 어떤 의미인지 궁금합니다.

안녕하세요. 토비님!현재 저는 강의 내용을 Kotlin springboot 로 따라가고 있습니다.JPA Entity 클래스를 생성할 때, 자바에선 롬복까지 이용해서 Getter 만 만들어놓고 setter 는 닫아놓는 게 쉽게 되는데, 이걸 코틀린에서는 롬복을 사용하지 않다보니 코틀린스러우면서도 깔끔하게 사용하는 방법에 대해서 애를 먹고 있습니다. 찾아보니 3가지 방법 있는 것 같습니다.방법1. 자바랑 가장 비슷하게, 필드를 모두 private 으로 생성하고 getter 는 롬복 대신 직접 선언.@Entity open class Member( @Column(name = "email", unique = true, nullable = false) private var email: String, @Column(name = "nickname", nullable = false) private var nickname: String, @Column(name = "passwordHash", nullable = false) private var passwordHash: String, @Column(name = "status", nullable = false) @Enumerated(EnumType.STRING) private var status: MemberStatus = MemberStatus.PENDING, ) { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) val id: Long = 0L fun getEmail(): String = email fun getNickname(): String = nickname fun getPasswordHash(): String = passwordHash fun getStatus(): MemberStatus = status } 방법2. getter 를 좀 더 코틀린스럽게 사용하기 위해 내부 필드를 _를 붙여서 선언 @Entity class Member2( @Column(name = "email", unique = true, nullable = false) private var _email: String, @Column(name = "nickname", nullable = false) private var _nickname: String, @Column(name = "passwordHash", nullable = false) private var _passwordHash: String, @Enumerated(EnumType.STRING) @Column(name = "status", nullable = false) private var _status: MemberStatus = MemberStatus.PENDING, ) { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) val id: Long = 0L val email: String get() = _email val nickname: String get() = _nickname val passwordHash: String get() = _passwordHash val status: MemberStatus get() = _status }방법3. protected set 사용@Entity open class Member3( email: String, nickname: String, passwordHash: String, status: MemberStatus = MemberStatus.PENDING, ) { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) val id: Long = 0L @Column(name = "email", unique = true, nullable = false) var email: String = email protected set @Column(name = "nickname", nullable = false) var nickname: String = nickname protected set @Column(name = "passwordHash", nullable = false) var passwordHash: String = passwordHash protected set @Column(name = "status", nullable = false) @Enumerated(EnumType.STRING) var status: MemberStatus = status protected set } 방법4(?). 전부 public val 로 선언하고, 변경시 새로운 객체 생성@Entity @Table(name = "members") class Member4( @Id @GeneratedValue(strategy = GenerationType.IDENTITY) val id: Long = 0L, @Column(name = "email", unique = true, nullable = false) val email: String, @Column(name = "nickname", nullable = false) val nickname: String, @Column(name = "passwordHash", nullable = false) val passwordHash: String, @Column(name = "status", nullable = false) @Enumerated(EnumType.STRING) val status: MemberStatus = MemberStatus.PENDING, ) { fun updateNickname(newNickname: String): Member4 { require(newNickname.isNotBlank()) { "Nickname cannot be blank" } return Member4( id = this.id, email = this.email, nickname = newNickname, passwordHash = this.passwordHash, status = this.status, ) } } 어느 방식을 선택하는게 현명할까요? 토비님은 평소에 어떻게 하시는지 궁금합니다.

안녕하세요섹션5 코드 다듬기까지 들은 시점에서 테스트 코드를 여러번 실행했을때 간헐적으로 실패를 경험합니다혹시 해당 내용 수정하는 부분이 끝까지 들으면 나오나요아래 에러내용 삽입했습니다. Failed to resolve parameter [com.clean.splearn.application.provided.MemberFinder memberFinder] in constructor [com.clean.splearn.application.provided.MemberFinderTest(com.clean.splearn.application.provided.MemberFinder,com.clean.splearn.application.provided.MemberRegister,jakarta.persistence.EntityManager)]: Failed to load ApplicationContext for [WebMergedContextConfiguration@350ec690 testClass = com.clean.splearn.application.provided.MemberFinderTest, locations = [], classes = [com.clean.splearn.SplearnApplication], contextInitializerClasses = [], activeProfiles = [], propertySourceDescriptors = [], propertySourceProperties = ["org.springframework.boot.test.context.SpringBootTestContextBootstrapper=true"], contextCustomizers = [org.springframework.boot.test.autoconfigure.OnFailureConditionReportContextCustomizerFactory$OnFailureConditionReportContextCustomizer@476fe690, org.springframework.boot.test.autoconfigure.actuate.observability.ObservabilityContextCustomizerFactory$DisableObservabilityContextCustomizer@1f, org.springframework.boot.test.autoconfigure.properties.PropertyMappingContextCustomizer@0, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverContextCustomizer@6dd1c3ed, [ImportsContextCustomizer@49cb1baf key = [com.clean.splearn.SplearnTestConfiguration]], org.springframework.boot.test.context.filter.ExcludeFilterContextCustomizer@7fdab70c, org.springframework.boot.test.json.DuplicateJsonObjectContextCustomizerFactory$DuplicateJsonObjectContextCustomizer@a451491, org.springframework.boot.test.mock.mockito.MockitoContextCustomizer@0, org.springframework.boot.test.web.client.TestRestTemplateContextCustomizer@2aff9dff, org.springframework.boot.test.web.reactor.netty.DisableReactorResourceFactoryGlobalResourcesContextCustomizerFactory$DisableReactorResourceFactoryGlobalResourcesContextCustomizerCustomizer@15639440, org.springframework.test.context.support.DynamicPropertiesContextCustomizer@0, org.springframework.boot.test.context.SpringBootTestAnnotation@cbfbc3c], resourceBasePath = "src/main/webapp", contextLoader = org.springframework.boot.test.context.SpringBootContextLoader, parent = null] org.junit.jupiter.api.extension.ParameterResolutionException: Failed to resolve parameter [com.clean.splearn.application.provided.MemberFinder memberFinder] in constructor [com.clean.splearn.application.provided.MemberFinderTest(com.clean.splearn.application.provided.MemberFinder,com.clean.splearn.application.provided.MemberRegister,jakarta.persistence.EntityManager)]: Failed to load ApplicationContext for [WebMergedContextConfiguration@350ec690 testClass = com.clean.splearn.application.provided.MemberFinderTest, locations = [], classes = [com.clean.splearn.SplearnApplication], contextInitializerClasses = [], activeProfiles = [], propertySourceDescriptors = [], propertySourceProperties = ["org.springframework.boot.test.context.SpringBootTestContextBootstrapper=true"], contextCustomizers = [org.springframework.boot.test.autoconfigure.OnFailureConditionReportContextCustomizerFactory$OnFailureConditionReportContextCustomizer@476fe690, org.springframework.boot.test.autoconfigure.actuate.observability.ObservabilityContextCustomizerFactory$DisableObservabilityContextCustomizer@1f, org.springframework.boot.test.autoconfigure.properties.PropertyMappingContextCustomizer@0, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverContextCustomizer@6dd1c3ed, [ImportsContextCustomizer@49cb1baf key = [com.clean.splearn.SplearnTestConfiguration]], org.springframework.boot.test.context.filter.ExcludeFilterContextCustomizer@7fdab70c, org.springframework.boot.test.json.DuplicateJsonObjectContextCustomizerFactory$DuplicateJsonObjectContextCustomizer@a451491, org.springframework.boot.test.mock.mockito.MockitoContextCustomizer@0, org.springframework.boot.test.web.client.TestRestTemplateContextCustomizer@2aff9dff, org.springframework.boot.test.web.reactor.netty.DisableReactorResourceFactoryGlobalResourcesContextCustomizerFactory$DisableReactorResourceFactoryGlobalResourcesContextCustomizerCustomizer@15639440, org.springframework.test.context.support.DynamicPropertiesContextCustomizer@0, org.springframework.boot.test.context.SpringBootTestAnnotation@cbfbc3c], resourceBasePath = "src/main/webapp", contextLoader = org.springframework.boot.test.context.SpringBootContextLoader, parent = null] at java.base/java.util.Optional.orElseGet(Optional.java:364) at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) Caused by: java.lang.IllegalStateException: Failed to load ApplicationContext for [WebMergedContextConfiguration@350ec690 testClass = com.clean.splearn.application.provided.MemberFinderTest, locations = [], classes = [com.clean.splearn.SplearnApplication], contextInitializerClasses = [], activeProfiles = [], propertySourceDescriptors = [], propertySourceProperties = ["org.springframework.boot.test.context.SpringBootTestContextBootstrapper=true"], contextCustomizers = [org.springframework.boot.test.autoconfigure.OnFailureConditionReportContextCustomizerFactory$OnFailureConditionReportContextCustomizer@476fe690, org.springframework.boot.test.autoconfigure.actuate.observability.ObservabilityContextCustomizerFactory$DisableObservabilityContextCustomizer@1f, org.springframework.boot.test.autoconfigure.properties.PropertyMappingContextCustomizer@0, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverContextCustomizer@6dd1c3ed, [ImportsContextCustomizer@49cb1baf key = [com.clean.splearn.SplearnTestConfiguration]], org.springframework.boot.test.context.filter.ExcludeFilterContextCustomizer@7fdab70c, org.springframework.boot.test.json.DuplicateJsonObjectContextCustomizerFactory$DuplicateJsonObjectContextCustomizer@a451491, org.springframework.boot.test.mock.mockito.MockitoContextCustomizer@0, org.springframework.boot.test.web.client.TestRestTemplateContextCustomizer@2aff9dff, org.springframework.boot.test.web.reactor.netty.DisableReactorResourceFactoryGlobalResourcesContextCustomizerFactory$DisableReactorResourceFactoryGlobalResourcesContextCustomizerCustomizer@15639440, org.springframework.test.context.support.DynamicPropertiesContextCustomizer@0, org.springframework.boot.test.context.SpringBootTestAnnotation@cbfbc3c], resourceBasePath = "src/main/webapp", contextLoader = org.springframework.boot.test.context.SpringBootContextLoader, parent = null] at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:180) at org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:130) at org.springframework.test.context.junit.jupiter.SpringExtension.getApplicationContext(SpringExtension.java:351) at org.springframework.test.context.junit.jupiter.SpringExtension.resolveParameter(SpringExtension.java:337) ... 3 more

안녕하세요. 토비님!먼저 제가 정말 오랜 기간 고민해온 주제에 대해서 이렇게 강의를 내주셔서 너무 감사드립니다!!특히 강의에서 여러 차례에 걸쳐서 깊게 다룬, "JPA Entity Class 와 Domain Model Entity Class 를 분리해야 하는가?" 에 대한 토비님의 의견이 너무 공감되고 유익했습니다! 감사합니다!그리고 이에 대해서 두 가지 질문이 있습니다.첫 번째는,저는 사실 지난 3년 간 스타트업에서 Domain Entity 와 JPA Entity 를 분리해서 사용해왔습니다.그런데 강의에서 다뤄주신 내용이 제가 겪으며 갖게 된 생각과는 결이 조금 다르다고 느껴서 이렇게 질문을 드리게 되었습니다.제가 느꼈던 "Domain Entity 와 JPA Entity 를 분리해서 사용했을 때의 장단점"은 이랬습니다.장점 1. 도메인 모델의 수정이 DB 데이터 마이그레이션을 꼭 강제하는 게 아니라서, 도메인 모델 수정이 매우 자유롭습니다.상황에 따라 의도적으로 JPA Entity 클래스와 도메인 모델 클래스를 다른 모양으로 만들어두고 유지할 수 있습니다.(ex. User, UserDetail 이 쪼개져 있었는데, 어떠한 의사결정으로 인해 User 하나로 합쳐서 관리하는게 맞다는 판단이 든 경우, UserEntity, UserDetailEntity 는 놔둔 채로 User 만 합치는 게 가능.)장점 2. 도메인 모델들을 완전히 정규화된 구조로 가져갈 수 있습니다. 회사에서 비즈니스가 발전하다보면 종종 어쩔 수 없이 테이블에 성능을 위한 반정규화 필드나 soft delete 용 deleted_at 필드 등을 넣게 됩니다. 하지만 사실 이런 필드들은 순수 비즈니스 로직을 기술하는데에는 방해가 될 뿐인, 너무 Technical 한 부분들입니다. 이러한 반정규화 or 기능 필드들을 도메인 모델에는 넣지 않고 JPA Entity 에만 넣어서 어댑터에서 처리하면, 도메인 모델 내에서는 항상 순수 비즈니스 로직만을 기술할 수 있게됩니다.단점 1. JPA 의 lazy loading 을 활용할 수 없습니다. 항상 도메인 모델 객체는 완전한 상태로만 존재합니다. 그래서 성능 문제로 CQRS 패턴이 강제됩니다. 특히 저는 GraphQL 을 사용중이라 더욱 더 CQRS 가 필요했습니다.단점 2. Repository 의 save(= upsert) 로직을 직접 구현해야 합니다. 특히 복잡한 비즈니스의 핵심 도메인 모델들은 관계된 테이블도 많아가지고 이 save 구현이 엄청나게 길어집니다. 저는 이 save 로직을 직접 구현하고 관리할 때 회의감이 가장 많이 들었습니다. Spring Data JPA 가 그 동안 얼마나 압도적인 생산성을 제공해주고 있었는지도 느끼게 됐습니다.저는 스타트업에서 일하고 있다보니 특히 생산성을 중요하게 생각합니다.그런 점에서도 위의 장점들과 단점들이 모두 너무 치명적으로 느껴졌습니다.그래서 이 관점들에 대한 토비님의 의견과 토비님이 제 상황이시라면 어떤 선택을 하셨을지가 너무너무 궁금합니다. (참고로 저는 Kotlin Springboot + Spring Data JPA + Kotlin JDSL + GraphQL-Kotlin(code first)을 사용하고 있습니다.)두 번째는,사실 저는 Kotlin Springboot 를 사용중인데, 코틀린 언어와 JPA 가 너무 안 어울린다는 생각을 종종 합니다.예를 들면, DB table 에 정의된 column default 값을 쓰려면 JPA Entity 의 해당 필드에 null 을 넣어서 보내야하는데, 보통 테이블 컬럼에 default 를 쓰는 경우는 대부분 해당 컬럼이 not null 타입입니다. 그래서 당연히 JPA Entity 에도 필드 타입은 not null 로 하고 싶어집니다.물론 @Column(insertable=false)를 사용하긴 하지만, 결국 그럼 이 JPA Entity 객체를 생성할 때 해당 필드에 실제로 저장되지도 않을 값을 거짓으로 넣어야 하는 상황이 생깁니다.그래서 조금 더 Kotlin 에 잘 맞는 Exposed 를 고려하자니, 도메인 모델 클래스와 JPA Entity 클래스 분리가 강제되는 느낌이고, 이게 과연 JPA 의 생산성을 따라올 수 있을까? 올바른 선택이 맞을까? 하는 의문이 듭니다.그래서 궁금한 점은,혹시 토비님이 추천하시는 좀 더 Kotlin 언어에 잘 맞고 Kotlin Springboot 를 생산적으로 사용할 수 있는 방법이 있을까요?

안녕하세요? 존경하는 토비님 작은 질문하나 드리겠습니다. 회원 애플리케이션 기능 추가의 25:00~26:00 에서는 MemberFinder 인터페이스를 정의하고 기존 MemberService에 혼재된 멤버 조회로직을 CQRS에 따라 구현클래스를 분리했습니다. 그리고 이를 MemberModifyService에서 사용하고 있습니다.말씀 주신 것처럼 단순히 조회이고 변경이 없다는 가정하에 이처럼 인터페이스를 정의하고 이를 통해 사용을 하는 것은 잘 이해가 됩니다!다만 저는 같은 계층에서 있는 서비스 빈이 서로를 의존하지 않는 방향으로 개발을 해오고 있었는데요. 그래서 토비님의 방식에 대해 공부하면서 같은 계층에서 인터페이스 포트를 통해서 호출하는 것은 괜찮을까 고민이 들었습니다.만약 그게 설계적으로도 문제가 없다면 앞으로도 토비님의 방식으로 개발하고 싶은데요. 분명 토비님께서 오랫동안 고민하신 개발 원칙/기준이 있을 것 같아서 여쭤봅니다.같은 계층에 있는 애플리케이션 서비스 빈이 서로를 의존, 또는 인터페이스를 통해 사용되는 경우 지켜야할 기준이나 원칙이 있을까요?*추신저는 토스의 김재님의 [블로그](https://geminikims.medium.com/%EC%A7%80%EC%86%8D-%EC%84%B1%EC%9E%A5-%EA%B0%80%EB%8A%A5%ED%95%9C-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EB%A5%BC-%EB%A7%8C%EB%93%A4%EC%96%B4%EA%B0%80%EB%8A%94-%EB%B0%A9%EB%B2%95-97844c5dab63)를 접해서 위와 같이 개발해오고 있었습니다. 저는 계층을 하나 두고 유틸성 빈을 만들고 이를 사용하게끔 했습니다.(블로그내용 아래 일부 발췌) > 네 번째 규칙동일 레이어 간에는 서로 참조하지 않아야 한다.(다만, Implement Layer는 예외적으로 서로 참조가 가능합니다.)

현재 Member 도메인 모델 확장 까지의 수업을 듣고 궁금한 것이 있습니다! 저희가 이번 수업을 포함하여 지금까지 요구사항(도메인) -> 도메인 모델(회원) -> 비밀번호 해시라는 일련의 과정을 통해 비밀번호 암호화와 관련한 도메인 모델의 규칙, 속성, 행위 등을 뽑아냈기 때문에 비밀번호 암호화까지 도메인 로직에 포함된다고 이해했습니다.  <인터페이스 위치를 결정하는 기준에 대해> 해당 답변에서도 PasswordEncoder를 어디에 둘지 결정할 때 사용한 기준은 도메인 모델을 이야기할 때 이게 등장하는가 라고 말씀해주시기도 했고요! 그렇다면 개발은 결국 요구사항을 토대로 진행되는 것이기에 모든 코드가 도메인 로직으로 분류되어야 하는 것 아닌가? 하는 의문점이 생겼습니다! 토비의 생각을 듣고 싶습니다!

안녕하세요 토비님. 강의 정말 잘 보고 있습니다.다름이 아니라 Auto Increment 전략을 현업에서도 자주 사용하시는지 궁금해서 문의드립니다. Mysql에서 Auto Increment를 사용하니 bluk insert가 안되는 구조던데 문제가 있으셨던 적은 없는지 궁금합니다. bluk insert를 jdbc template으로 구현했더니 갈레라 3중화 구조라 ID가 3씩 증가하는 문제가 있어서 곤란한 경험이 있습니다. 이럴 경우 ID 전략을 UUID나 Snowflake 이런식으로 가져가야 하는지 궁금합니다.아니면 다른 해결 방법이 있으시다면 알려주시면 감사하겠습니다.   

안녕하세요, 토비님.도메인 모델의 정의 범위에 대해 토비님의 생각이 궁금하여 질문드립니다. 현재 저는 MSA 환경에서 여러 시스템이 나뉘어 있는 구조에서 일하고 있습니다. 보통 팀에서는 “우리가 생성·저장하는 데이터 구조”를 도메인 모델로 이해하는 경우가 많은데요,저는 도메인 모델의 범위가 그보다 더 넓다고 생각하고 있습니다. 예를 들어, 주문시스템이 있다고 할 때, 주문시스템은 주문데이터를 생성/관리하는 책임을 지겠지만 이를 위해서여러 시스템(상품, 프로모션, 결제 등)에서 데이터를 조회해 조합하여 업무 규칙을 수행하는 책임을 가질 수 있습니다. 이 경우, 다른 시스템이 생성·관리하는 개념이라 하더라도,주문시스템 내부에서의 목적과 규칙에 따라 주문에 맞는 방식으로 추상화된 모델을 정의하는 것이바로 도메인 모델이라고 생각하는데요. 즉, 외부 개념이라도 주문시스템의 책임 하에 있는 로직과 규칙이 있다면, 그것은 주문의 도메인이다라는 관점입니다. 이와 같은 관점에 대해 토비님은 어떻게 생각하시는지,도메인 모델 정의의 기준에 대해 의견을 듣고 싶습니다. 감사합니다.

@Test void find() { Member member = memberRegister.register(MemberFixture.createMemberRegisterRequest()); entityManager.flush(); entityManager.clear(); Member found = memberFinder.find(member.getId()); assertThat(member.getId()).isEqualTo(found.getId()); }현재 코드에서 위와 같이 테스트에서 회원 저장을 위해 memberRegister.register를 호출하고 있습니다.그런데 memberRegister.register에는 단순히 회원을 저장하는 것 외에도 이메일 전송 같은 부가적인 로직이 포함되어 있습니다. 이러한 부가적인 로직때문에 테스트 속도가 느려진다던가, 테스트가 실패하는 원인이 될 수 있다고 생각이 들었습니다.이처럼 테스트 준비에 필요하지 않은 부가 로직까지 수행되는 상황에서, memberRegister.register를 테스트 준비 용도로 사용하는 것이 적절한지 토비님의 생각이 궁금합니다.

도메인 모델에서의 검증과 애플리케이션 레벨 검증의 경계에 대해 질문드립니다.현재 도메인 모델에서는 이메일 형식이 올바른지, 닉네임이나 비밀번호가 null이 아닌지 같은 최소한의 조건만 검증하고 있습니다. 반면, 비밀번호가 8자 이상인지, 닉네임이 5자 이상인지 같은 검증은 애플리케이션 레이어에서 처리하고 있습니다. 그런데 닉네임이 5자 이상이어야 한다 같은 규칙도 도메인 규칙으로 볼 수 있지 않을까 라고 생각이 들어 해당 검증 역시 도메인 모델에서 처리하는게 맞지 않나 라는 생각이 드는데,도메인 모델에서의 검증과 애플리케이션 레벨 검증의 경계는 어디까지 두는 게 좋은지 토비님 의견이 궁금합니다.말씀하신것을 토대로 예측해 봤을때 형식이나 정책적 요구사항(변경 가능성이 있는 규칙)은 애플리케이션 레이어에서, 도메인의 본질적 불변 조건은 도메인에서 검증하는 걸까요?

Member#create() 메서드를 register로 공통언어를 바꾸셨는데, 뜻이 모호해진 것 같아서 질문드립니다! 제가 생각하기에 register(등록)이라는 단어는 생성과 영속화라는 두가지의 행위를 함축한 단어로 느껴집니다. 따라서 MemberService#register()는 너무 자연스럽습니다. 실제로 Member를 생성한 후에 MemberRepository를 통하여 영속화까지 하는 내용으로 구현되어있습니다.하지만 Member#register()는 이와 다르게 Java 객체를 생성하기만 하는 것이라, 메서드명과 실제 동작이 불일치한다고 느껴집니다. 하지만 또 동시에 도메인 모델을 글로 작성하는 과정에서 '멤버를 등록한다.' 라는 말을 쓰는 것은 자연스럽습니다. 그 구현이 코드적으로 Member에 있는 것만이 부자연스럽습니다.이런 경우에는 Member라는 객체만으로 도메인 모델을 온전히 표현해내기가 어려운 것일까요? 해당 모델을 표현하기 위해서는 MemberService 같은 코드가 꼭 필요한 걸까요?

멤버를 저장하는 테스트에서 EntityManager#flush()를 호출해서 플러시되어 DB까지 쿼리문이 제대로 가는지 검증하시는 것을 보았습니다. (저는 플러시까지 테스트해볼 생각을 못했어서 아주 인상깊었습니다 ㅎㅎ) 하지만 해당 부분이 검증문 없이 홀로 호출되고 있습니다.좀더 의도를 드러내기 위해서는 assertThatCode(() -> em.flush()).doesNotThrowAnyException() 처럼 코드를 작성하는게 더 좋지 않을까 싶어서 질문드립니다!적용 예시@Test void 멤버를_저장한다() { var member = MemberFixture.createAny(); memberRepository.save(member); assertThat(member.id()).isNotNull(); assertThatCode(() -> em.flush()) .doesNotThrowAnyException(); }

MemberRepositoryTest는 EntityManager 나 @DataJpaTest 등 Jpa와 깊게 관련되어있는 테스트로 이해됐습니다. EntityManager#flush() 가 잘 호출되는지 확인하는 부분도 그런 이유에서 이해됩니다.하지만 테스트명이 MemberRepositoryTest인 점에서 헷갈리는 부분이 발생합니다. MemberRepository 인터페이스의 메서드를 테스트하는 것이 목적이라면 좀 더 추상화된 테스트를 작성하는 것이 옳지 않았나? 라는 것이 주된 궁금증입니다. 물론 Spring Data JPA 특성상 런타임에 구현체가 만들어지기 때문에, 테스트 대상은 인터페이스를 사용해야 한다는 것은 이해합니다만, 최소한 클래스명은 좀 더 구체적으로 작성해주는 것이 의도에 부합하지 않나? 해서 질문드립니다! 어떻게 생각하시나요?

해당 코드에서 자기 자신의 프로필 address와 비교하는 로직을 도메인에게 맡기는 건 어떨까요? 토비님! 이렇게 해도 되는건지 아니면 따로 빼신 이유가 있으신 지 궁금합니다. private void checkDuplicateProfile(Member member, String profileAddress) { if (profileAddress.isEmpty()) return; Profile currentProfile = member.getDetail().getProfile(); if (currentProfile != null && currentProfile.address().equals(profileAddress)) return; if (memberRepository.findByProfile(new Profile(profileAddress)).isPresent()) { throw new DuplicateProfileException("이미 존재하는 프로필 주소입니다: " + profileAddress); } }이런 식으로요!private void checkDuplicateProfile(Member member, String profileAddress) { if (profileAddress.isEmpty()) return; if (!member.isProfileNull() && member.isProfileEquals(profileAddress)) return; if (memberRepository.findByProfile(new Profile(profileAddress)).isPresent()) { throw new DuplicateProfileException("이미 존재하는 프로필 주소입니다: " + profileAddress); } }

안녕하세요, 토비님. 주니어로서 아직 부족한 점이 많지만, 궁금한 점이 있어 또 이렇게 질문드립니다.Section 3에서 소개된 splearn 도메인 강의를 듣기 전에, 스스로 먼저 도메인 모델링을 해보는 시간을 가졌습니다.그 과정에서 회원, 수강, 강의 등의 개념 외에 수강신청이라는 도메인을 도출했는데요, 그 이유는 “수강은 수강신청 후 결제가 완료되어야 성립된다”는 제 안의 암묵적인 경험에 의한 도메인 해석 때문이었습니다.그런데 사실 강의에서 제시된 사용자 스토리에는 결제라는 개념이 존재하지 않았습니다. 그럼에도 불구하고, 과거 경험에서 비롯된 도메인이 자연스럽게 설계에 스며들었고, 결과적으로 오버엔지니어링으로 이어졌다는 생각이 들었습니다.이런 식의 ‘의도되지 않았지만 그럴듯한 도메인’을 설계에 넣고 싶은 유혹은 실제 회사에서 설계할 때도 자주 느끼는 부분입니다.그래서 토비님께서는 이런 상황에서 어떤 기준으로 도메인을 포함하거나 배제하시는지, 그리고 본인의 경험을 어떤 방식으로 설계에 녹이시는지가 궁금해졌습니다.바쁘시겠지만, 짧은 의견이라도 들려주시면 큰 도움이 될 것 같습니다. 감사합니다!

안녕하세요 토비님, 강의 너무 재미있게 듣고 있습니다.인터페이스를 도메인 계층에 둘지, required 포트에 둘지 결정하는 기준이 있을까요?Splearn의 코드를 예로 들어보면, 도메인 서비스 인터페이스인 passwordEncoder는 어댑터 계층에서 구체적인 기술로 구현된다는 점에서 EmailSender, MemberRepository 같은 required 포트의 인터페이스와 유사하게 느껴집니다. 이들 모두 외부 세계(또는 특정 기술)와 애플리케이션을 분리하는 역할을 하기 때문입니다.만약 애플리케이션 서비스에서 passwordEncoder를 사용해 비밀번호를 암호화한 후, 암호화된 비밀번호(passwordHash)를 Member.register 메서드에 인자로 직접 넘겨준다면, passwordEncoder 역시 required 포트에 위치할 수 있지 않을까요? 도메인 계층도 애플리케이션 서비스에 의존하지 않게 되고요.그런데도 불구하고 passwordEncoder를 도메인 계층의 인터페이스로 두신 이유가 궁금합니다.감사합니다.

안녕하세요, 토비님. 메서드 파라미터가 많아질 경우 record 타입의 parameter object를 사용하여 가독성을 높일 수 있는 방법을 소개해주셨는데요,이 방법으로도 parameter object 인스턴스 생성 시 argument를 잘못 전달한다거나 등의 휴먼 에러는 여전히 발생 가능하지 않나 생각이 듭니다.java record도 kotlin의 named parameter와 같은 기능을 제공하면 좋겠지만 검색해봤을땐 아직 제공하지 않는 것 같더라구요. 이처럼 argument 전달 버그는 예방할 방법이 없을까요? 혹은 강의 뒷부분에서 이러한 점을 개선해주실까요?record에 builder를 사용해야 하나 생각이 들긴 하는데, 괜찮은 방법인지는 물음표네요.

안녕하세요. 토비님강의가 마치 의도하신 것 처럼 시니어 개발자님과 함께 개발하면서 의논하는 느낌으로 진행되어서 재밌게 잘 수강하고 있습니다.강의 내용에서 DDD는 도메인이 복잡해진 순간에 택해야 한다. 라는 말씀을 해주셨는데요.문득, "토비님이 생각하시는 도메인이 복잡해진 순간은 어떤 순간일까? 나름의 기준이 있으신걸까?" 하는 생각이 들었습니다.개인적으로 저는 어떻게 생각할까 라고 고민을 해봤는데요. 1) 도메인을 설명하기 위해서 개발자가 코드를 살펴봐야 하는 순간2) 각 도메인 간의 결합도가 고객의 유스케이스를 해결하기 위해 다양하게 결합되어야 하는 경우이 두 가지가 떠올랐는데, 토비님의 견해가 궁금해서 질문드려봅니다!늘 양질의 강의를 제공해주셔서 감사드립니다. (_ _)

안녕하세요 토비님, 강의 너무 잘 듣고 있습니다.이메일 패턴 테스트 관련해서 궁금한 부분이 생겨 질문을 드립니다.해당 강의를 기준으로 기존 : Member 엔티티에서 패턴 검증변경 후 : Email 값객체에서 패턴 검증 변경 후 단계에서 Email 값 객체에 패턴 검증하는 로직이 들어갔기에 해당 로직에 대한 테스트는 EmailTest 에 들어가야 하지 않는가? 라는 생각이 들어요.해당 부분에 대해 의견을 여쭙고 싶습니다.감사합니다.

안녕하세요 토비님! 강의 너무 잘듣고 있습니다. 애그리거트 쪽 강의를 들으면서 문득 든 생각을 질문드립니다.현재 사내에서 하고 있는 프로젝트는 JPA를 전혀사용하지 않고 Mybatis만을 사용하고 있는데요 이런 경우에도 에그리거트라던가 헥사고날 아키텍쳐를 적용하면서 진행하는게 충분히 가능할까요? 그게 아니라면 기존에 적용하고 있는 흔히 말하는 레이어드 아키텍쳐 및 트랜잭션 스크립트 방식으로 진행하는게 더 나은 방법일까요?혹시라도 수준 떨어지는 질문이라면 사과드립니다.감사합니다.