안녕하세요. 강의 잘 보았습니다. 몇가지 궁금증이 생겼는데요. Aggregate간의 의존성과 결합도를 해소하기 위해 보통의 DDD 예제에서 Event를 사용하는 법을 많이 알려주고 있는데요. 이 방식을 채택하기에 모종의 이유로 실무에서 적용하지 못한다고 하였을때는 어떤식으로 의존성을 제거 또는 낮출수 있는지 궁금합니다. 두번째로는 회원 도메인에서의 회원과 주문 도메인의 회원, 그리고 배송 도메인에서의 회원이 각 도메인별로 갖는 의미와 역할/기능 이 다를것 같은데요. 예를 들어 주문 context에서 회원에게 특정 기능이 필요하다고 가정했을때 이 코드가 어떤 entity에 작성이 되어야 하는지 궁금합니다. 기존의 user entity에 코드를 작성해야 되는지 아니면 order context내에 user entity를 새로 만들어서 코드 작성해야 되는지 궁금합니다.
aggregate 영역이 엔티티(product)와 엔티티(review)간의 생명 주기가 밀접한 관계를 갖고 있는 것들을 하나의 영역으로 묶은 것이라고 말씀해주셨는데 그럼 농심이라는 brand가 있고 농심 브랜드에 속한 양파링, 새우깡이 있을 경우에 어느날 농심 브랜드가 퇴점을 하게된다면 농심이라는 brand의 product인 양파링, 새우깡은 같이 삭제가 될테니 brand와 product를 aggregate 영역으로 묶을 수 있는건가요?
특정 비즈니스 문제를 설명하는 거대한 도메인에 서브 도메인으로 핵심, 지원, 범용이 있다는 것은 알겠는데요. 그럼 바운디드 컨텍스트는 각각의 서브 도메인과 1:1로 동등한 관계로 매칭이 되는걸까요? 아니면 각각의 서브 도메인 안에 바운디드 컨텍스트가 있고 바운디드 컨텍스트의 갯수는 1개가 아니라 여러개가 될 수 있을까요? 또 아니면 바운디드 컨텍스트 안에 서브 도메인이 들어가고 바운디드 컨텍스트 안에 여러개의 서브 도메인이 있을 수 있을까요? 마지막으로 서브 도메인안에 또 작은 도메인들이 있을 수 있을까요??
앱에서 DDD를 적용해보려고하는데 어려움이 있어 질문드립니다. 앱단에서 어플리케이션 레이어의 서비스는 어떻게든 식별해서 진행이되는데 어그리게잇, 엔티티, 값 객체에서 막막하게 느껴집니다. 막막하게 느껴지는 이유는 결국 데이터를 최종적으로 받아서 저장하는 로직들은 서버단에서 처리를 할 텐데요. 이런 경우에 결국 앱에서는 임시로 데이터를 들고 있는 자료구조 혹은 vo라고 느껴지고 있습니다. 아니면 앱이라는 환경속에서 어그리게잇, 엔티티, 값 객체를 뽑는 것도 생각을 했는데 아직 머리속으로 구조가 잡히지 않고 어떤 방향으로 가는게 좋은지 확신이 들지 않는데요. 어떻게 나아가야할지 좋은 의견 부탁드립니다.
질문 드립니다! 질문1) 강의내용을 생각해보면 Bounded Context 단위도 하나의 서버가 될 수 있고 Aggregate 단위도 하나의 서버가 될 수 있는 것으로 보이는데 제가 이해한게 맞을까요? 질문2) 또한 Aggregate 와 마찬가지로 Bounded Context 도 다른 도메인으로의 요청은 Event 사용을 해야하는 걸까요? 질문3) 주문 Entity - 주문 아이템 Entity 관계가 Aggregate 로 연상됩니다... Bounded Context 개념이 적용된 코드가 Aggregate 쪽 코드와 다를까요?
이전 강의에서 Product 와 Brand 를 join 하지 않고 각각 Select 함으로서 성능상의 불이익이 있었는데 Aggregate 단위로 묶여있었기 때문이군요. 데이터의 일관성을 위해 Aggregate Root 를 통해 접근가능하도록 연습 많이 해보도록 하겠습니다!
안녕하세요 😀 혹시 강의 때 사용하신 코드 제공이 가능할까요? 아직 Service 와 useCase 와의 경계에 대해 감이 안잡혀서 코드로 확인해 보고 싶습니다 PS. 강의에서 Service class 와 useCase 모두 Repository 를 참고하고 있어서 어떠한 다른점이 있는지도 질문드립니다
안녕하세요. 질문이 많네요. review를 저장하는 코드를 보았습니다.. product를 db에서 읽고, 해당 product관련된 모든 review를 읽고, 새로운 review를 추가하고, transaction을 걸고, product 저장하고, review들을 다시 저장하도록 하는 구조로 보입니다. 어떤 의도인지는 이해는 갑니다. 궁금한점은 review만 추가하는데도 기존 product를 저장하려고 시도하는건가요? 만약 기존리뷰들의 저장은 conflict되면 무시하는건가요? 리뷰가 보통 수백 수천건 되는 경우가 많을 텐데 그런건 고려가 안된것일까요? 확인 부탁드립니다. 감사합니다.
안녕하세요. value object를 사용하는 이유를 잘 이해했습니다. 저같은 경우는 보통 외부에서 controller로 넘어올 때 값을 체크하고 기본타입을 그대로 많이 써 왔거든요. 강사님 은 실제 프로젝트에서 이렇게 vo를 다 만들면서 하시는지 궁금하네요. 가끔 비즈니스 로직에서 유닛테스트를 한다고 할때는 email등의 값이 정상인지 체크를 해야하나 고민이 되긴 하더라고요. vo를 쓰면 정상 값이기 때문에 그런 고민을 안해도 되겠네요. 다만 코드량이 어마어마하게 많아지니 배보다 배꼽이 더 커질것 같긴하네요. 확인 부탁드립니다. 감사합니다.
안녕하세요. 파라메터를 phone: string으로 하면 바로 다음줄의 비교처리를 안해도 될 것 같은데 혹시나 외부모듈등을 통해 any값이 넘어 와서 이렇게 처리하시는 건가요? (만약 외부모듈에서 그런값이 넘어올 경우라면 타입을 체크한 후 값을 쓰면 될것같긴 한데요.) 확인 부탁드립니다. 감사합니다.
강사님 덕분에, EDA, DDD, 헥사고날 등 어려운 개념에 대해 좀더 친숙해질 수 있어서 너무 감사합니다! 강의를 다 듣고 몇가지 궁금증이 생겨 질문 남겨요! 대여 취소, 반납 취소 등으로 보상트랜잭션이 필요한 경우, 보통 클라이언트에게 알림(?)은 어떻게 보내나요? 알림 서버를 사용하나요? EDA 시, 1개의 서버의 응답이 너무 느린 경우, 비동기더라도 느릴수 있는데, 이럴 걸 대비하여 자체적으로 타임아웃시간을 정해서 해당 시간 초과면 시간 초과 응답을 클라이언트한테 보내나요?
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요. 도메인모델을 만들때 Entity와 VO는 단순히 불변성을 가지고 구분하는 것인지요? 그리고 JPA에서의 Entity와는 다른 개념인지 궁금합니다. 감사합니다.
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요! 좋은 강의 감사드립니다 ㅎㅎ (강의에서 나온대로 패키지와 클래스를 구성한 상태입니다.) 혹시 DTO를 framework 패키지에 넣는 이유가 있을까요? 저는 개인적으로 UseCase나 InputPort에 framework 패키지에 대한 import가 생기기 때문에 의존성이 생긴다고 판단해 application에 DTO를 생성할 것 같습니다. 혹시 제가 생각하지 못한 다른 이유가 있는지 궁금합니다!
