안녕하세요! 강의 잘 듣고있습니다. 질문이 두 개 있는데요, 1/ RentalCard라는 도서 대여 카드로 Entity를 구성하셨는데, 이벤트 스토밍때 한 번도 Card라는 개념이 나오지 않은 것 같습니다. DDD 자체가 유비쿼터스 언어로 기술되어야하는 것으로 이해했는데, Card라는 키워드가 이벤트 스토밍때 도출되지 않는걸로 봐서는 비즈니스 언어라고 하기 어려울 것 같습니다. 이 상황에서 RentalCard라는 네이밍을 지으신 이유가 있을까요? 2/ RentalCard 도메인 자체에 ReturnItem을 쥐고있어, 이 설계에서는 Aggregate가 매번 ReturnItem 리스트를 조회하게 됩니다. 사용자 대여 목록이 쌓이게 되면 이 리스트가 매우 커질수도 있을 것 같은데, 이러한 문제는 현업에서 어떻게 처리하나요?
안녕하세요. 요새 조회 메서드 네이밍 컨벤션에 대해 고민 중인데요. Repository 계층을 제외한 애플리케이션, 도메인 등 계층에서 조회(DB 조회 아닌 경우도 포함) 관련 메서드 명를 작성할 때 네이밍 컨벤션에 대해 고민 중입니다. find를 쓰자니 Spring Data 관례인거 같아 이외 계층에서도 꼭 이렇게 사용할 필요가 있을거 같기도 해서 어떤 방식이 좋을지 조언을 듣고 싶습니다. 현재 생각 중인 3가지 네이밍이에요. 앞에 있는게 데이터가 없을시 예외가 발생하는거고, 뒤에가 없으면 null(또는 Optional) 반환입니다. get / find getOrThrow / get get / getOrNull
안녕하세요! 강의를 열심히 듣다가 돌연 멀티 모듈이라는 주제로 생각하다가 질문을 남깁니다! 현재 강의에서는 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); } 이러한 판단이 객체지향의 캡슐화, 정보 은닉 관점에서 올바른지 궁금합니다.
9월 8일 세션 진행한 거는 없었을까요? 그날 다른 행사 운영자로 참여하느라 20시에 세션이 있었던 것 같았는데 뭔가 놓친 느낌이 들어서요... 만약 9월 8일날 세션이 없었다면 다행이고, 있었다면 대략 어느 내용이었는지, 어떻게 진도를 나아가야 할지 살짝이라도 알려주시면 감사드리겠습니다.
안녕하세요. 미션1을 수행하려고 하는데 진행 방법이 막연합니다. 내려받은 git소스는 이미 헥사고날아키텍쳐로 구성이 되어있는 상태인거같은데 어떤 소스, 혹은 브랜치를 기준으로 클린아키텍쳐로 리팩터링해서 제출하여야 할까요? 아니면 주문, 상품, 결제 시스템을 처음부터 설계해서 클린아키텍쳐로 작성하라는게 미션의 취지인가요? (이 경우 각 도메인별 요구 기능도 임의로 가정해서 작성해야 하나요?)
안녕하세요. 토비님 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개 이상일땐 좀 난감해지더라고요.
안녕하세요. 강의 잘 듣고있습니다. 오늘 수강한 "엔티티 식별자와 JPA 엔티티" 에서 JPA 엔티티로 만들었다고해서 달라진게 없다 라고 표현하셨는데요. 애노테이션을 붙여서 컴파일 단계의 의존성은 생겼지만 해당 클래스가 다른 기술적 종속이 생긴건 아니라고 말씀하신거에 질문이 있습니다. 일단 애노테이션을 붙인 것을 용인할 수 있다는건 이해했고, 저도 동의합니다. 그런데 JPA 엔티티가 됨으로써 해당 클래스는 final 로 만들 수 없고, 생성자도 기술적 요구사항에 의해 최소 protected 로 공개할 수 밖에 없는데요. 이번 강의에서도 기존 의도는 private 이었지만 기술을 도입함으로써 애노테이션을 붙이는 것 이상의 작업이 있었습니다(생성자의 접근 수준 변경). 정말 애노테이션만 붙이고 아무것도 하지 않았다면 납득할 수 있지만 애노테이션 외에 다른 변경이 발생했는데도 기술적 종속이 없다고 볼 수 있을까요? 이정도 수준의 변경과 의존은 트레이드오프로 용인할 수 있다고 생각하면 할수는 있지만 엄밀히 따진다면 객체 설계에 영향을 줬다고 생각하는데, 어떻게 생각하시는지 궁금합니다.
헥사고날 아키텍처와 DDD를 적용할 때, 화면에 강하게 연관된 조회 데이터를 어떻게 다루는 게 좋은지 궁금합니다. 예를 들어 채팅방 목록 화면에서 각 채팅방마다 다음 정보를 한 번에 보여줘야 한다고 가정하겠습니다 . ex) 채팅방 이름, 마지막 채팅 내용, 읽지 않은 채팅 개수 이 정보를 구하려면 room, chat, read_status 같은 여러 테이블을 함께 조회해야 하고 , N+1 문제를 피하려면 Querydsl 이나 JDBC 등을 사용해서 한 번의 쿼리로 조회하는 방식이 필요해 보입니다 . 이 경우 제 생각에는 기존 포트와 분리해서 , 조회 전용 port 와 query repository interface 를 application 계층에 두고 , adapter 계층에서 Querydsl/JDBC/MyBatis 등으로 구현하는 것이 해결책 같습니다. 이런 식으로 cqrs패턴을 적용하는 것이 유일한 해결책인가요? 혹시 더 나은 방법이 있는지 궁금하여 질문남깁니다. (강의 너무 잘 보고 있습니다)
안녕하세요. Member 객체를 생성할 때, 다른 방법을 선택해 보는 것은 어떨까요? 기존에는(설계 트레이드 오프 개선 전) Member.register() 가 MemberRegisterRequest 에 직접 의존하고 있었는데, 도메인 모델이 요청 DTO를 알지 않도록 의존성을 반대로 두는 방법입니다. MemberRegisterRequest 에서 Member 객체를 직접 생성하는거죠. public record MemberRegisterRequest( ... ) { public Member toMember(PasswordEncoder passwordEncoder) { return Member.register(email, nickname, password, passwordEncoder); } } public class Member extends AbstractEntity { ... public static Member register(String email, String nickname, String password, PasswordEncoder passwordEncoder) { Member member = new Member(); member.email = new Email(email); member.nickname = requireNonNull(nickname); member.passwordHash = requireNonNull(passwordEncoder.encode(password)); member.status = MemberStatus.PENDING; member.detail = MemberDetail.create(); return member; } ... } public class MemberModifyService implements MemberRegister { ... @Override public Member register(MemberRegisterRequest registerRequest) { checkDuplicateEmail(registerRequest); Member member = registerRequest.toMember(passwordEncoder); memberRepository.save(member); sendWelcomeEmail(member); return member; } ... } MemberRegisterRequest.toMember(passwordEncoder) 에서 Member.register(email, nickname, password, passwordEncoder) 를 호출하면 Request DTO → Domain 방향으로만 의존합니다. 별도의 MemberRequestInfo 같은 파라미터 객체도 필요하지 않아 구현이 단순합니다. Request DTO를 단순 데이터 전달 객체로 유지하려면 서비스 계층에서 각 값을 꺼내 Member.register() 에 전달하는 방법도 가능합니다. (이 방법보다는 이전 방법이 서비스 계층을 간결하게 유지하는 방법이긴 합니다.) 이런 방법을 기본 개발 규칙으로 두면, 의존성 방향도 문제 없고, 추가적인 객체(예: MemberRequestInfo )를 생성할 필요도 없어서 충분한 이점이 있습니다. 다만, register() 에 전달해야 할 파라미터가 많아진다면 번거롭긴 하겠네요. 이 방법에 대한 의견도 부탁 드립니다. 감사합니다.
안녕하세요. 우선 좋은 강의 제작해주신 토비님께 항상 감사하고 있어요. 이제 배운지 1년된 왕초보입니당.. 혼자 배워보면서 개인 프로젝트를 만들고 있는데 JPA를 사용하고 있어요. 제가 궁금한 것이... N+1 관련한 문제입니다. 아 일단 프로젝트 주제는 복식부기 가계부에요. @Entity ... public class Journal extends BaseEntity { @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "ledger_id", nullable = false, updatable = false) @OnDelete(action = OnDeleteAction.CASCADE) private Ledger ledger; ... @OneToMany(mappedBy = "journal", fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true) private List<EntryLine> entries = new ArrayList<>(2); ... public EntryLine getEntryLine(EntrySide side) { switch (side) { case CREDIT : this.entries.stream().filter(line -> line.isCredit()).findFirst() .orElseThrow(...); case DEBIT : this.entries.stream().filter(line -> line.isDebit()).findFirst() .orElseThrow(...); default : throw new ... } } ... // Service에서 저장되기 전에 호출 public void validateSavable() { ... validateJournalSave(); } private void validateJournalSave() { AccountType debit = getEntryLine(EntrySide.DEBIT).getAccountType(); AccountType credit = getEntryLine(EntrySide.CREDIT).getAccountType(); if(!this.transactionType.isValidPlacement(debit, credit)) { throw new ... } } } Journal Class에서 EntryLine List에 접근하고 있어요. 그리고 EntryLine Class는 이렇게 생겼어요. @Entity ... public class EntryLine extends BaseEntity { @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "journal_id", nullable = false, updatable = false) private Journal journal; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "account_id", nullable = false) private Account account; ... // private package 접근제어자 사용 // Account는 Category를 참조중이에요. AccountType getAccountType() { return this.account.getCategory().getAccountType(); } } 거래가 저장되기 전에 Journal : validateJournalSave() 에서 this.transactionType에 따라 차변과 대변에 올바르게 위치하고 있는지 검사한 후 저장하고 있는데 이것을 생성과 수정할 때 두 곳에서 사용하고 있어요. Ledger에 5개 Category가 있고, Account는 그 Category를 참조하고 Category에서만 AccountType이 있어요. Journal이 각 EntryLine의 AccountType을 얻기 위해 Journal -> EntryLine -> Account -> Category -> getAccountType() 이렇게 흘러가네요. 이렇게 접근해도 설계상 괜찮은걸까요? Journal을 저장할때는 @Query 사용해서 Fetch Join으로 필요한 Account를 가져오고 있는 상황이에요. Journal이라는 엔티티가 비즈니스 로직 수행을 위해서 다른 엔티티의 필드까지 깊게 참조?? 가져오도록 설계하는게 옳은건지 모르겠어요.
안녕하세요. 도메인 모델을 설명하는 부분에서 관계와 규칙을 온라인 서점 운영 예시로 간단히 언급해주셨습니다. 강의를 들으면서 실제 업무 도메인에 관계와 규칙을 구분지으며 간단히 개인 실습을 해보았는데요. 적다보니 어느샌가 관계에 규칙이 섞이기도 하더라고요. 문득 이런 생각이 들었습니다. '관계와 규칙의 차이는 무엇인가?' 관계와 규칙을 명확하게 구분지으려면 어떤 기준을 갖고 생각해야할까요? 관계는, DB 모델에 워낙 익숙하다보니 하나의 OO은 여러 OOO을 갖는다. 이쪽으로 먼저 생각이 흐르기도 하고요. 예시로 들어주신 것을 보면 관계는, '비즈니스에서 관계'라는 생각이 듭니다. 규칙은 데이터를 변경할 때 필요한 조건이라고 생각하면 될까요? 토비님 의견이 궁금합니다.
