VO Money 에서 add(money:Money) 함수에 대해서 궁금합니다.VO는 불변인데 Money를 초기화 해서 값을 재할당 하는건지 어떤식으로 이해하면 좋을지 궁금합니다.

Entity를 설계 하다가 자주 변하지만 응집도가 높은 값들은 어떻게 해야할까요?자주 변하지만 응집도가 높은 값들은 VO를 사용한다.VO로 선언된 값의 수정은 불가능 하지만 생성으로 값을 초기화 한다.그냥 이러한 상황에서는 응집도가 높아도 VO를 고려하지 하지 않는다.수정 기능이 필요하다면 VO가 아닌 Entity를 고려해야 한다? 

안녕하세요. 강의 잘 보았습니다.몇가지 궁금증이 생겼는데요. Aggregate간의 의존성과 결합도를 해소하기 위해보통의 DDD 예제에서 Event를 사용하는 법을 많이 알려주고 있는데요. 이 방식을 채택하기에 모종의 이유로 실무에서 적용하지 못한다고 하였을때는 어떤식으로 의존성을 제거 또는 낮출수 있는지 궁금합니다.  두번째로는회원 도메인에서의 회원과 주문 도메인의 회원, 그리고 배송 도메인에서의 회원이 각 도메인별로 갖는 의미와 역할/기능 이 다를것 같은데요.예를 들어주문 context에서 회원에게 특정 기능이 필요하다고 가정했을때 이 코드가 어떤 entity에 작성이 되어야 하는지 궁금합니다.기존의 user entity에 코드를 작성해야 되는지아니면 order context내에 user entity를 새로 만들어서 코드 작성해야 되는지 궁금합니다.

학습 내용과는 관련없는 질문이지만...이제 12월이 거의 다 지나가는데 다음 강의는 언제쯤 나오나요?

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가 결국 이벤트를 기반으로 비즈니스적으로 응집력 있게 관리되어야 하는 데이터들을 어떻게 핸들링할 것인가 인것 같은데, 제가 맞게 이해한 걸까요? 이를 위해서는 결국 도메인 중심적으로 생각하는게 좋구요!

강사님 덕분에, EDA, DDD, 헥사고날 등 어려운 개념에 대해 좀더 친숙해질 수 있어서 너무 감사합니다!강의를 다 듣고 몇가지 궁금증이 생겨 질문 남겨요! 대여 취소, 반납 취소 등으로 보상트랜잭션이 필요한 경우, 보통 클라이언트에게 알림(?)은 어떻게 보내나요? 알림 서버를 사용하나요?EDA 시, 1개의 서버의 응답이 너무 느린 경우, 비동기더라도 느릴수 있는데, 이럴 걸 대비하여 자체적으로 타임아웃시간을 정해서 해당 시간 초과면 시간 초과 응답을 클라이언트한테 보내나요?

강의를 듣다보면, 여러 MS 사용되는 클래스의 경우, 복붙해서 사용하시는데, 실무에서는 여러 MS 사용되는 클래스의 경우 어떻게 처리하나요? MS 서버별로 팀이 다르다고 했을 때에는 복붙으로만 해결되지 않을 수도 있을 것 같아서요!

코드를 보면, Adpater 클래스와 Repository 인터페이스, 이렇게 2곳에서 @Repository을 사용하고 계시는데, 2곳에서 사용하시는지 이유가 궁금합니다!