안녕하세요. 강의 잘 듣고있습니다. 오늘 수강한 "엔티티 식별자와 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을 갖는다. 이쪽으로 먼저 생각이 흐르기도 하고요. 예시로 들어주신 것을 보면 관계는, '비즈니스에서 관계'라는 생각이 듭니다. 규칙은 데이터를 변경할 때 필요한 조건이라고 생각하면 될까요? 토비님 의견이 궁금합니다.
강의 잘듣고 있습니다! 도출된 애그리거트와 의문이 생겨 질문드립니다. 제가 알고 있는 Aggregate는 "여러 객체를 하나의 일관된 단위로 묶은 클러스터" 이고, Aggregate Root가 존재하며 외부에서는 Root를 통해서만 접근해야 한다고 이해하고 있습니다. 근데 노란 포스트잇으로 도출된 애그리거트 들은 객체를 하나의 일관된 단위로 묶은 클러스터의 개념은 아닌거 같아서요 세번째 강의의 코드만 대략 보고왔는데 이벤트 스토밍으로 도출된 애그리거트와는 조금 다른거 같아 질문드립니다ㅜ_ㅜ
안녕하세요, 이번 강의를 통해 처음으로 헥사고날 아키텍처에 대해서 공부하고 있는 사람입니다. 헥사고날 아키텍쳐를 지키면서 배치, 시큐리티, 이벤트 처리 등등 다양한 기술을 어떻게 사용하나요? 제가 공부해본 바로는 1. 배치: 애플리케이션 계층에 배치를 통해 이루어질 api를 만들어두고, 어댑터 계층엔 배치(Job, Step, Writer, Reader등 )에 관한 설정들을 위치하게 한다. 2. 시큐리티: 전부 어댑터에 위치한다. 이벤트 처리: 이벤트는 도메인으로 간주하고 도메인 계층에 위치시키고, 이벤트 리스너는 어댑터 계층에 위치시킨다. 이벤트를 발행시키는 로직은 애플리케이션 계층에 위치하고, ApplicationEventPublisher 같은 경우는 추상화됐다고 판단하고 그냥 사용하거나, 혹은 인터페이스를 따로 만들어서 사용한다. 이정도인데 큰 흐름에서 제가 이해한 게 맞을까요? 특히 궁금한 건 "이벤트가 도메인으로 간주되어도 문제가 없는지" 입니다. (무조건 도메인이기 보다는 로직을 처리하기 위해 존재하는 dto로 볼 수도 있는 거 아닌가 싶어서요.) 다른 기술들을 헥사고날 아키텍쳐에 적용시킬 때 주의할만한 사항들도 따로 존재를 할까요?
안녕하세요. 좋은 강의 잘듣고 많이 배우고 있습니다. 좋은 강의 만들어주셔서 감사합니다. 다름이 아니라, 어댑터에서 엔티티에 의존성을 가지는 것이 크게 문제되지 않는다고 말씀주신 내용에 의문이 있어 질문드립니다! 어댑터에서 도메인에 직접 의존하는 것을 막기 위해서 변환 역할을 하는 매퍼 클래스나 DTO에서 엔티티를 자기 자신으로 변환하는 로직을 가지는 것은 어떨까요? 타이트하게 룰을 잡는 케이스를 가정한다면, application layer 내부에 port가 존재할 것이고 이 port에서 return 하는 dto도 application layer일 것이고, 이 dto 안에서 Entity를 받아서 자기 자신으로 변환하는 로직을 가진다면 entity가 application 밖으로 나가지 않을 수 있지 않을까요? (controller, repository 등 마찬가지입니다) 그리고 dto를 application에서 변환하는 것이 로직의 침투라고 표현하시기도 했는데, 그렇다면 provided port 역시 어댑터의 요구가 침투하는 구조라고 볼 수도 있을 것 같기도 합니다.. (생각해보니 이상적으로는 계층별로 DTO를 생성하는게 맞다고 생각은 들지만, "엔티티를 반환하는 트레이드오프가 굉장히 효율적이고 정당하다"라고 말씀하신 것 같다고도 생각이 듭니다) 강의에서 항상 기술이 등장한 배경과 사상을 이해하고, 이를 바탕으로 정당하게 규칙을 스스로 정하는 것을 강조하시는 것 같습니다. 그래서 강의에서 말씀하신 내용이 비슷한 맥락으로, "절대 노출되면 안된다"라는 것에 대한 반박이라고 받아들여지긴 합니다만.. 그래도 바깥쪽으로 노출하지 않는 것이 의존성 관리 차원에서 더 좋지 않을까하는 생각에 질문드립니다!
예제에서는 도메인에 별도 PasswordEncoder 인터페이스를 정의해 사용하고 있습니다. 만약에, Member 도메인이 Spring Security의 PasswordEncoder 인터페이스를 직접 의존한다면, 구현체가 아니라 인터페이스를 참조하더라도 순수 도메인 설계 관점에서 위반으로 봐야 할까요? 저는 인터페이스 의존이라 괜찮을 수 있다고 생각했지만 AI는 도메인에서는 자체 PasswordEncoder 포트만 사용하고, Spring Security PasswordEncoder는 인프라 어댑터에서 위임하는 것이 좋다. 고 제안했습니다. 토비님은 어느 쪽이 더 적절하다고 보시는지, 판단 기준도 함께 듣고 싶습니다.
안녕하세요, 토비님. 강의 초반에 말씀해 주신 것처럼, 리팩토링 과정에서 “제가 했다면 어떻게 했을까”를 계속 생각해 보며 토비님의 의사결정 과정을 따라가고 있습니다. MemberService.register() 메소드에서 emailSender.send(...) 를 sendWelcomeEmail() 로 분리하시는 과정을 보며 두 가지 고민이 생겼습니다. 첫째, 환영 이메일의 내용이나 정책이 변경될 때마다 MemberService 의 코드가 함께 변경되어야 한다면, 이는 SRP 위반에 해당하지 않는지에 대한 고민입니다. 이 경우 환영 이메일 전송에 대한 책임을 EmailSender 인터페이스 쪽으로 옮기는 것이 더 적절한지 궁금해졌습니다. 둘째, 만약 EmailSender 인터페이스에 해당 메소드를 추가한다면, 구현체가 늘어날수록 인터페이스가 비대해지거나 향후 구현 복잡도가 증가할 수 있다고 느꼈습니다. 이런 경우 default method 로 제공하는 방식에 대해서는 어떻게 생각하시는지도 궁금합니다.
MemberDetail 테이블의 UK_MEMBER_DETAIL_PROFILE_ADDRESS 유니크 제약 조건과 관련해서 질문이 있습니다. 39장 강의 마지막 부분에서, 해당 프로파일 주소(profile_address)를 빈 문자열로 바꿔 삭제할 수 있는 부분 테스트를 추가 하셨는데, 그런데 이렇게 되면 여러 사용자가 프로필 주소를 빈값으로 변경 할 경우 제약 조건에 충돌이 발생할 수 있을 것 같습니다. profile_address 값을 빈값으로 설정할 수 없도록 테스트를 조정하는게 더 맞아 보이는데 제가 생각한게 맞을까요?
안녕하세요 msa에서 db를 각자 쓰게되는 패턴이라면 join이 깨지지 않나 하는 생각이 들었습니다. 혹시 join을 하다가 db가 나뉘게되어 쿼리 효율이 떨어지는 경우도 있을까요? 아니면 애초에 join이 안쓰이기 때문에 마이크로서비스로 분리가될까요 예를들어 사용통계같은걸 볼 땐 모노리스에서 msa 전환 전에 join이 들어갈 수 있을 것 같은데, db가 나뉘어버리면 join을 못쓰는거죠? 그럼 msa 전환해야한다면 그때가 데이터레이크를 만들 타이밍인걸까요?
안녕하세요 토비님!! 강의를 완강하고 제 프로젝트를 리팩토링하면서 피드백받고싶은점이 생겨 질문글을 올립니다. Repository Port를 기술에 종속시키지 않기 위해 Adapter에서 JPA, MyBatis, QueryDSL을 조합하는 구조를 선택했는데, 이 설계 방향이 적절한지 조언을 구하고 싶습니다. 현재 구조 core/ └── domain/ └── application/ └── required/ ← Port 인터페이스 └── ~Repository adapter/ └── persistence/ ├── ~RepositoryAdapter ← Port 구현체 ├── ~JpaRepository ← Spring Data JPA └── ~MybatisMapper ← Mybatis 매퍼 인터페이스 의존 관계 [Service] → [Repository] ←impl― [RepositoryAdapter] → [JpaRepository] → [MybatisMapper] → [JPAQueryFactory] (core) (core) (adapter) (adapter) 예시 @Repository @RequiredArgsConstructor public class ItemRepositoryAdapter implements ItemRepository { private final ItemJpaRepository itemJpaRepository; private final ItemMybatisMapper itemMybatisMapper; @Override public List<Item> findBySearchRequest(ItemSearchRequest request) { return itemMybatisMapper.findBySearchRequest(request) .stream() .map(Item::from) .toList(); } @Override public List<Item> saveAll(List<Item> items) { return itemJpaRepository.saveAll(items); } } @Repository @RequiredArgsConstructor public class AuctionRepositoryAdapter implements AuctionRepository { private final JPAQueryFactory jpaQueryFactory; private final AuctionJpaRepository auctionJpaRepository; @Override public void deleteAllByRegionAndRealmId(RegionType region, Long realmId) { QAuction qAuction = QAuction.auction; BooleanBuilder filter = new BooleanBuilder(); filter.and(qAuction.region.eq(region)); if (realmId == null) { filter.and(qAuction.realmId.isNull()); } else { filter.and(qAuction.realmId.eq(realmId)); } jpaQueryFactory.delete(qAuction) .where(filter) .execute(); } @Override public int saveAll(List<Auction> auctions) { if (auctions.isEmpty()) return 0; return auctionJpaRepository.saveAll(auctions).size(); } } 이 구조를 선택한 이유 동적 쿼리, 벌크 연산 등 JPA만으로 해결하기 어려운 케이스가 있어 MyBatis와 QueryDSL을 병행 사용하고 있습니다. 일반적인 방식인 Port 인터페이스가 Spring Data JPA Repository를 상속하는 구조를 채택하지 않은 이유: MyBatis나 QueryDSL 기반 구현체를 만들 수 없음 CustomRepository 인터페이스를 별도로 만들어야 하는 복잡도 증가 현재 방식의 장점: Port 인터페이스가 순수 Java 인터페이스로 유지됨 RepositoryAdapter에서 상황에 맞는 기술을 자유롭게 조합 가능 추가 인터페이스 없이 단순한 구조 유지 저는 현재 구조가 의존 관계도 외부에서 내부로 향하고 테스트도 쉬워서 괜찮다고 생각하는데 토비님의 생각도 듣고싶습니다!! 좋은 강의 감사합니다!!
spring-boot 버전 4.0.0 으로 프로젝트를 생성하면 어플리케이션 구동 시 아래와 같은 오류가 발생합니다. (현재 2025-12-08) 3.x 버전으로 내리면 발생하지 않으니 참고해주세요. 2025-12-08T18:40:05.881+09:00 INFO 2496 --- [splearn] [ main] .s.b.d.c.l.DockerComposeLifecycleManager : Using Docker Compose file /Users/coffeenjava/work/study/splearn/compose.yaml 2025-12-08T18:40:06.285+09:00 ERROR 2496 --- [splearn] [ main] o.s.boot.SpringApplication : Application run failed tools.jackson.core.exc.StreamReadException: Unexpected character ('\' (code 92)): expected a valid value (JSON String, Number, Array, Object or token 'null', 'true' or 'false') at [Source: REDACTED StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION disabled); byte offset: #UNKNOWN] at tools.jackson.core.JsonParser._constructReadException(JsonParser.java:1800) ~[jackson-core-3.0.2.jar:3.0.2]
