묻고 답해요
160만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
애그리거트의 repository
안녕하세요 토비님! 애그리거트를 사용할 때 질문 사항이 있습니다.예) A도메인 B도메인이 있다 A는 애그리거트 루트이고 B는 A의 부속 엔티티이다.A와 B는 일대다, 다대일의 양방향 의존성을 가진다.B는 A를 통해서만 조작될 수 있다.이 때 B를 생성하거나 업데이트 할 때 B의 repository는 어디에 존재해야 하는가?@Entity public class A { @OneToMany(mappedBy = "media", cascade = CascadeType.ALL, orphanRemoval = true) private List<B> bs = new ArrayList<>(); public void updateNumber(long n){ this.bs.stream().forEach(b -> b.update(n); } } @Entity public class B { @ManyToOne(fetch = FetchType.LAZY) private A a; private long number; public void update(long n){ this.number = n; } } 이렇게 되어 있다고 할 때 변경 가능성을 생각할 때(물론 엔티티에서 이미 jpa에 기술을 사용하고 있긴하지만) B의 repository를 따로 가지는게 맞나요? 만약 따로 가진다면 B의 repository가 A repository에서 의존하여 처리 되어야 하나요?jpa에 완전 종속적으로 사용하면 B가 따로 repository를 가질 필요 없는데 순수함을 유지하지 하려 하니 이 부분에서 고민이 되네요. 아니면 이런 고민 자체가 잘못된걸까요?
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
Domain Expert가 정확히 어떤 역할을 하는 사람인가요?
도메인 모델을 만들기 위해서는 Domain Expert에게서 듣고 배워야 한다고 말씀하셨는데, 이들의 정확한 역할이 잘 이해가 가지 않습니다.온라인 서점을 예로 들자면 제 머리속에 상상되는 Domain Expert는 실제 서점을 운영하는 사장님이 떠오르는데 강의에서는 회사에서 해당 일을 오랫동안 해 오신 분이나, 관련된 시스템을 개발해 본 경험이 있는 시니어 개발자 같은 사람을 Domain Expert라고 말씀 주셨습니다.그렇다는건 Domain Expert 라는 역할은 이 회사가 개발하고 있는 서비스를 가장 잘 알고 있는 사람 (그것이 개발자가 되었든, 디자이너, po와 같은 비 개발자가 되었든)이라고 이해해도 되는 것일까요?
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
회원 애플리케이션 서비스 테스트 (1)
회원 애플리케이션 서비스 테스트 (1) 12:46초 부분EmailSenderMock에 getter 어노테이션이나 메서드가 없는데 어떻게 getTos를 사용하신 걸까요..?
-
미해결Readable Code: 읽기 좋은 코드를 작성하는 사고법
안녕하세요 메서드명 때문에 고민이 있어서 질문드립니다.
안녕하세요 강사님제가 create 메서드 명에 대해서 고민중인데private void createTip(RequestTipDto requestTipDto, User user) { Tip tip = Tip.builder().title(requestTipDto.getTitle()).content(requestTipDto.getContent()).user(user).build(); tipRepository.save(tip); } private Tip createTip(RequestTipDto requestTipDto, User user) { Tip tip = Tip.builder().title(requestTipDto.getTitle()).content(requestTipDto.getContent()).user(user).build(); return tip; } tipRepository.save(tip); 첫번째 코드는 create메서드 안에 tip을 빌더로 생성하고 save까지 같이 하는 코드입니다.두번째 코드는 tip을 빌더로 생성 후 리턴하고 해당 createTip을 호출한 메서드에서 save를 하는 코드입니다. 첫번째 코드는 둘이 같이 할 수있다는 장점이 있고, createTip하고 save를 또 따로 할 필요가 없는 장점이 있고두번째 코드는 나중에 재상용성이나, create메서드안에서는 create만 하는 SRP(단일책임원칙)을 하고 있다는 것이 장점입니다. 위 두가지 방법중 어느것이 더 좋은 방법일까요?그리고 위처럼 builder를 사용하는 코드는 길기 때문에 이를 service 클래스에서 따로 빼서 하는게 좋은지 아니면 entity 클래스에서 하는게 좋은지 궁금합니다. 강의 잘 보고 있습니다.
-
해결됨토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
정적 팩토리 메서드 관련 질문드립니다!
안녕하세요 토비님 궁금한점이 생겨 질문을 남깁니다.예제를 진행하실때 정적팩토리 메서드를 통해 객체를 반환할때생성자를 통하지않고 바로 멤버변수에 값을 넣어 반환하는걸 사용하셨는데 public static Member register(MemberRegisterRequest createRequest, PasswordEncoder passwordEncoder) { Member member = new Member(); member.email = new Email(createRequest.email()); member.nickname = requireNonNull(createRequest.nickname()); member.passwordHash = requireNonNull(passwordEncoder.encode(createRequest.password())); member.status = MemberStatus.PENDING; member.detail = MemberDetail.create(); return member; }이게 가능한 원리는 이해를 했습니다만 AI와 이야기하다보니 아래와 같은 이유를 제시하면서 생성자를 통한 반환을 강력 추천하더라구요부분 초기화 위험: 생성 직후 한동안 불완전 상태일 수 있어요. (중간에 예외가 나면 더더욱)final 을 못 씀: 생성자 밖 대입이 필요하니 final로 못 고정합니다(불변성/스레드 가시성 이점 상실).검증 누락 가능성: 검증/정규화가 흩어지기 쉬움 → 생성자 경로에 모으는 게 안전. 토비님 생각은 어떠하신지 궁금합니다.
-
해결됨토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
required 포트에 관해서
안녕하세요 토비님현재 파트1에서는 아직 required 포트에있는 repository 인터페이스를 다른 도메인에서 사용하고 있지 않아서 중복이 발생하고 있지 않지만, 만약 다른 도메인에서도 같은 리포지토리를 사용해야할 경우 어떻게 하면 좋을지 질문드립니다. 제가 생각한건 첨부한 이미지와 같습니다. 도메인별로 각각 required 포트에 MemberFinder 인터페이스를 선언하고 그것을 Adapter layer에서 각각 도메인 별로 구현합니다. 하지만 실제 로직은 Adapter레이어에 있는 MemberRepository를 부르는 역할만 할 뿐입니다
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
혹시 다음 편은 언제쯤 오픈할까요?
안녕하세요 토비님. 강의 잘 수강하고 있습니다.아직 강의 초반부만 들었지만, 아주 감명깊게 수강중입니다.혹시 다음강의 오픈은 언제쯤 예상하고 계실까요?
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
서비스 단위 테스트 코드 작성
MemberFinder 와 같은 유즈케이스 단위로 통합 테스트를 분리 해서 작성하셨는데 단위 테스트의 경우에는 분리를 어떻게 하시나요? MemberService (Query, Modify) 가 없이는 코드가 작성이 되질 않아서 질문 드립니다.
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
domain 모듈에 entity를 정의한다고 했을때
안녕하세요. 궁금한게 있어서 질문 드립니다.domain 패키지에 entity를 위치 한다고 했을때 주석이라고 말씀하신 어노테이션 JPA @Entity를 만들어서 Member로 정의그리고 mongo DB도 필요해서 @Document를 정의해서 domain 패키지에 위치 시켜 Member로 정의이처럼 같은 도메인이 서로 다른 DB로 사용 될때 어떻게 도메인으로 정의해야할지 궁금합니다.그리고 이름이 중복되는 현상도 발생하기도 합니다. 그렇다고 OracleMember, MongoMember로 지을수도 없는것같습니다. 제 생각은 Member라는 도메인이 Domain 패지키에 별도로 나와서 adapter 안에 JPA Persistent의@Entity로 정의된 클래스와Mongo Persistent의 @Document로 정의된 클래스가 위치 되어야한다고 생각하는데 어떤 의견이신지 궁금합니다.
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
여러 엔티티의 조합으로 리포트를 제공해야할 때
안녕하세요 실무에서 헥사고날을 적용 예정 중에 있습니다. 이미 DB 모델링이 되어 있고 하나의 우리 팀 시스템이 아닌 여러 팀의 시스템에서 같은 테이블을 바라보는 경우 헥사고날 적용은 어떻게 해야하는지 궁금합니다. 하나의 애그리거트로 만들 수 없는 여러 엔티티의 조합으로 조회를 할 경우, 예를 들어 백오피스에서 20개 이상의 조건과 각 조건이 여러 테이블에 나뉘어져있어 Join을 걸어야 할 경우의 도메인 모델과 리턴은 어떻게 해야하는지 궁금합니다.
-
해결됨토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
Member와 MemberDetail 엔티티를 나누는 기준에 대해
안녕하세요.강의 정말 잘 들었습니다. 강의를 듣다가 궁금한 점이 있어 질문 남깁니다.Member와 MemberDetail을 별도 엔티티로 분리한 기준이 궁금합니다.관계가 1:1인 경우에는 엔티티에 너무 많은 필드가 있는 것이 아니면 하나로 관리하는 게 더 개발 편의성이 좋지 않을까? 하는 생각이 들기도 합니다. 실제로 회원 정보 수정 시에 닉네임, 프로필 주소, 자기소개를 한 번에 변경하도록 구현되어 있어, 두 엔티티가 함께 조회/수정되는 것처럼 보입니다.혹시 조회 성능 최적화를 위해 접근 빈도가 낮은 데이터를 지연 로딩하려는 의도인지, 아니면 회원의 본질적 속성(email, status 등)과 부가 정보(등록일시, 프로필 등)를 개념적으로 구분하기 위한 설계인지 궁금합니다.감사합니다.
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
핵사고날 아키텍처 책을 추천해주실 수 있으실까요??
안녕하세요 토비님언제나 헥사고날 아키텍처는 무엇이고 이걸 적용한다는 것이 왜 좋고 왜 필요하다는 것인지궁금했습니다. 이번 강의를 통해서 대략적인 흐름 어떻게 적용할 것인지 어떤 방향으로 작업 해야 하는지 살짝 이해할 수 있었습니다 조금 더 이해도를 높이고 싶은데.. 혹시 토비님께서 추천하시는 서적이 있으실까요??
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
MemberRegister 질문드립니다.
domain 패키지 안에 activate메서드가 있는데 포트 역할을 하는 MemberRegister 인터페이스에 activate메서드가 또 필요한 이유가 어떤건가요??activate는 외부로 공개될 필요가 없는거 아닌가용??
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
MemberService 코드 작성 중 질의
안녕하세요 실습 중 컴파일 오류가 왜 발생하는지 이해가 안되어 질문 남깁니다. private final MemberRepository memberRepository; private final EmailSender emailSender; private final PasswordEncoder passwordEncoder;해당 코드에서 EmailSender와 PasswordEncoder 부분에서 Could not autowire. No beans of 'EmailSender' type found. 컴파일 오류가 발생합니다. final을 제거하면 컴파일 오류가 발생하지는 않는데요 하지만 github 페이지에 올려주신 소스코드를 보면 현재 영상 시점과 코드 구조가 100% 일치하지는 않지만 스프링 빈 관련 설정을 따로 해준 것 같진 않아보입니다만.. 토비님 영상에서는 오류가 없고 제 코드에서는 컴파일 오류가 나네요. 어떤 시점에 따로 Spring Bean 관련 설정이 되어있는게 있다던가.. 아님 제가 빼먹은 부분이 있다면 알려주실 수 있으신가요? 문제가 되는 부분 전체 코드 첨부드립니다. 시간되실 때 확인 부탁드립니다. 감사합니다. package com.ggne.splearn.application.required; import com.ggne.splearn.domain.Email; /** * 이메일을 발송한다. */ public interface EmailSender { void send(Email email, String subject, String body); }package com.ggne.splearn.domain; public interface PasswordEncoder { String encode(String password); boolean matches(String password, String passwordHash); }
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
checkDuplicateEmail 메서드와 동시 요청에 관한 질문
안녕하세요 토비님! 좋은 강의 만들어주셔서 잘 듣고 있습니다.작은 질문이 하나 있는데요. checkDuplicateEmail 메서드와 동시 요청에 관한 질문이 있습니다.섹션 5. 28강 회원 애플리케이션 서비스 테스트(2) 20:47초 경에 email 중복 체크를 위하여 checkDuplicateEmail 메서드 코드를 작성하였고, 같은 email로 가입하려고 하면 DuplicateEmailException이 발생하는 것을 확인하였습니다. 그런데 여기서 다른 가정을 해보고 그런 상황에서 토비님이라면 어떻게 하셨을지 궁금합니다.만약 email이 아닌 id로 회원가입을 하는 상황을 가정한다면,email과 다르게 id는 여러 사람이 같은 id로 회원가입하려고 시도할 수 있습니다.따라서 동시에 2개의 요청이 들어오게 된다면 checkDuplicateEmail는 둘 다 통과하고 DataIntegrityViolationException이 발생하게 될 것입니다. (DB에서 유니크 제한을 걸었기 때문에)규칙인 id는 중복되지 않는다는 지켜지겠지만,사용자가 보게 될 예외는 우리가 의도했던 DuplicateEmailException가 아니게 되겠죠. 여기서 궁금한 점은 이런 상황까지 고려하여 코드를 작성하여야 하는 것인지아니면 그냥 넘어갈 것인지 궁금합니다. 저라면,드물게 발생할 것이라고 예상을 했다면 로깅만 잘 해놓고, 해당 예외가 많이 발생했거나 관련 cs문의가 많이 들어온다면 추가로 코드를 작성할 것 같습니다.처음부터 만약 많이 발생할 것이라고 예상했다면 try-catch를 통해 예외를 변경해줬을 것 같습니다.아마 다음과 같은 코드가 될 것 같습니다.@Override public Member register(MemberRegisterRequest registerRequest) { try { checkDuplicateEmail(registerRequest); Member member = Member.register(registerRequest, passwordEncoder); memberRepository.save(member); emailSender.send(member.getEmail(), "등록을 완료해주세요", "아래 링크를 클릭해서 등록을 완료해주세요"); return member; } catch (DataIntegrityViolationException e) { if (/*e를 통해 유니크 키 예외를 확인했다면*/) { throw new DuplicateEmailException(); } throw e; } }서비스의 코드가 현재보다는 보기 지저분해진다고 생각했습니다. (아니면 이 방법이 아닌 다른 방법이 있을까요?) 토비님은 어떻게 생각하시는지 궁금합니다.
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
아키텍처 선택 시 고려사항 질문입니다
이번 강의에서 아키텍처 설명과 interface를 활용해 계층 간 의존도를 끊는 방법을 보며 시야가 넓어지는 느낌을 받았습니다.토비님은 새로운 프로젝트를 시작하거나 기존 코드를 리펙토링할 때, 어떤 기준으로 아키텍처를 선정하는지 궁금합니다.팀원들의 지식 범위나 프로젝트의 뱡향성, 개발 속도 등 여러 요소 중 어떤 부분을 더 중요하게 고려하시는지도 듣고 싶습니다.
-
해결됨토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
실무적용 관련 질문드립니다
회사 규모상 프로젝트를 혼자서 개발하는 경우, 강의의 내용을 적용해서 도메인 문서를 만드는 것이 개발에 대한 정리나 추후 다른 사람이 봤을 때 도움이 될 수는 있으나, 당장 시간에 쫓기기도 하고 다른 사람의 피드백 없이 혼자서 정리하다 보면 잘 정리하기 힘들다는 생각이 되는데요. 이런 상황에서의 정리는 오히려 도움이 안될 수도 있다는 생각이 드는데, 토비님께서는 어떻게 생각하시는지 궁금합니다.
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
AI 시대에서 공부와 실무의 관계를 어떻게 바라봐야 할까요?
안녕하세요 토비님.강의에서 말씀하신 공부할 때는 AI 관련 도구를 끄고 지식을 습득 해야 한다는 부분이 인상 깊었습니다.이전에도 공부와 실무 사이에는 늘 간극이 있었고, 이번 강의는 그 간극을 인지하고 실무적인 관점에서 방향을 잡을 수 있도록 도와주신다고 느꼈습니다.그런데 요즘은 AI가 빠르게 보편화되면서, 공부와 실무의 관계가 또 다른 형태로 변화하고 있는 것 같습니다.실제로 신규 업무나 개인 프로젝트에서 AI의 활용 방식과, 기존 시스템을 지속적으로 개선하거나 확장하는 과정에서의 AI의 활용 방식이 다르게 느껴집니다.이런 변화 속에서 AI를 새로운 학습 형태이자, 학습과 실무를 잇는 새로운 도구로 봐야 할지, 아니면 보조적인 수단으로 바라봐야 할지 고민됩니다.토비님은 실무에서 AI를 어떤 방식으로 활용하고 계신지, 그리고 이 시대의 개발자가 어떤 균형점을 가져야 한다고 보시는지 궁금합니다.
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
도메인엔티티와 JPA 엔티티 분리 문의
안녕하세요. 도메인 엔티티와 JPA 엔티티를 아예 분리하는 case도 있는지 궁금합니다. 예를들어 Domain 패키지에는 순수한 도메인 클래스들만 모아놓고 JPA에선 도메인 엔티티 -> JPA엔티티로 변환해서 사용하는경우도 있나 궁금합니다.
-
미해결토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
헥사고날 아키텍처와 DDD
5년차 백엔드 개발자 이며 현재 섹션5. 헥사고날 아키텍처의 사실과 오해를 학습하고 있습니다.현업에서 신규 프로젝트를 준비 하면서 어떤 아키텍처를 가져가는 것이 좋을지 고민중에 강의를 접하게 되었습니다. 부동산 관련 데이터를 기반으로 한 서비스를 개발 및 설계 단계에 있습니다. 제가 전부 리드하는 것은 아니지만 프로젝트 전반적인 부분을 개발 리드분에게 권한을 받고 저와 팀원 둘이서 백엔드 구조를 설계 하고 있습니다.수천만건 그 이상이 될 수 있는 데이터를 기반으로한 서비스를 계획 및 설계하고 있는데, 자바 스프링으로 서버를 구축 하려고 하는데 헥사고날 아키텍처를 저와 팀원은 경험 하지 못하였는데, 확장성 있는 서비스를 만들기 위해 헥사고날 아키텍처 기반으로 어떤 구조 설계를 하는 것이 좋을지 ,,, 조언 부탁드립니다.