안녕하세요 질문이 있습니다.로그인 기능 구현 (Application Layer 실습) 강의에서 9:10초쯤에 스프링에서 디비객체를 도메인객체로 자동으로? 변환해주는게 있다고 하셨는데요. 어떠한 기능일까요? 알려주시면 감사하겠습니다.

도메인 주도 설계 책을 읽는 중에 오프라인 선점 잠금 부분에서 이해가 안되는 부분이 있어서 해당 책을 읽어보셨거나 구현을 해보신 분 중에 알고 계신 분 있으신가요?책에 나온 건 처음 세션 얻는 유저(A)가 접근했을 때, LockId를 LockManager로 생성하면 해당 반환된 LockId를 얻는 것까진 나와있는데 도메인이랑 엮어서 타임아웃 전 유저(B)가 LockId를 얻는 방법이 없더라고요. 해당 도메인 엔티티 내에 lock 관련 필드를 하나 만들고 A의 첫 번째 조회 트랜잭션이 끝나기 전에 저장한 다음 B가 그 데이터에 접근할 때, 얻는 방법 밖에 생각이 안나는데 해당 방법이 맞을까요?

UserCase가 많은데...그러니까 일반적인 Layered Architecture에서는 Service 기능으로, 현재 결국에는 RentalCard 관련해서 작업을 하니까 RentarCardService라는 interface파일에 모든 기능을 넣어서 사용할 수 가 있는데 현재 헥사고날 공부하면서 UseCase는 InqueryUsecase를 제외하고 기능 하나에 usecase하나로 작성이 되었더라고요. 이 이유와 이로 인한 장점이 무잇인지 잘 모르겠습니다.설명 부탁드립니다!

이런 부분은 빨리 보안해 주셔야 하지 않을까요?중간 내용이 알아 들을수 없어서 너무 답답 합니다.싼강의도 아니고... 만들어 진지 좀 된거 같은데 빠른 보안이 필요해 보입니다.그리고 인프런은 이런부분은 한번은 검증해야 하지 않나요.  

강사님 안녕하세요. 강의를 다 듣고 배운 내용을 개인 프로젝트를 통해 구현하는중입니다.제가 CQRS에 대한 오해가 있는 것 같아 질문 드립니다. CQRS는 도메인을 도메인 답게 유지하기 위해 비지니스 로직에 query가 침투하는 것을 막는다.즉 command, query를 역할에 따라 분리한다.라고 이해했는데요.  그렇다면, command만 수행하는 서버, query만 수행하는 서버로 분리하는게 맞을까요?로직상 command를 통해 데이터를 저장 혹은 업데이트하려고 하면, db에서 해당 데이터에 대한 조회가 필수적이라고 생각하는데 이러한 조회도 command의 한 종류라고 생각하면 되는걸까요? 

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. [내부영역:응용서비스 구현(어플리케이션 헥사곤)-InputPort구현,아우터 포트 정의]강의에서 음성이 불명확하고, 코드 포커스로 확대하신것같은데 잘린부분(클래스 명, 어노테이션 등)이 많아요

안녕하세요 선생님.  급한 마음에 강의를 구매하며 이렇게 문의글도 남기네요. 저는 이제 막 입사 반년 정도 된 주니어 백엔드 개발자 입니다. 회사에 별다른 사수는 없고 php만 쓰던 분들 몇분 계시는데 저 혼자 nestjs를 사용하고있고 레거시코드를 전부 nestjs로 바꾸라고해서 이 강의까지 오게되었습니다. 회사에서는 DDD가 뭔지는 잘 모르지만 요즘 좋다고하니 그걸로 해서 레거시코드를 다 변환하라고하는데 저는 DDD를 잘 알지못하는 상태이고물어볼 선임도 없고 마땅한 강의도 이것밖에 보이질 않아서요,,이 강의를 보면서 nest에 적용시키는것에는 크게 어려움이 없겠지요? ( 아직 보기 전인데 익스프레스 기반 인것같아서요 ,, 개념만 이해하면 구조 잡는것에는 문제가 없겠죠? ) 소개 페이지에 나와있는 메일로 문의를 드려도 문의에 대한 답변을 받을 수 있는지도 궁금합니다. 🙂  

MSA강의 재밌게 잘 보고 있습니다 👏 강의를 보던 중 카프카 연동을 위해 kafkaadapter와 event 패키지를 정의하고 객체들을 넣고있는데, 저희 회사에서도 겪고 있는 문제가 떠올라서 궁금한게 생겼는데,  프로듀싱하는 서비스와, 컨슘하는 서비스의 프로토콜을 ItemReturned, ItemRented등으로 정의하고 내부 값에서IDName등을 사용한다고 할 때 이 프로토콜 스펙이 변경될 때마다 각 팀별로 객체 정보를 수정한다고 하면, 마치 서비스내에 코드 중복들이 된 상태에서 기능이 변경될때마다 중복된 코드들을 같이 관리하며 싱크를 맞춰줘야하는 작업들과 유사해보이는데, 이에 대해서는 어떻게 풀어나가야 하나요?  즉, 서비스간에 데이터 송수신을 위한 객체들이 중복코드처럼 보이는데 스펙변경이 있을때마다 각 서비스마다 직접 코드 수정을 하는건 한 팀에서 수정을 누락하거나 관리를 놓친 프로젝트에서 수정이 누락되면 문제가 될 수 있을 것 같은데 어떤식으로 풀어나가는지 궁금합니다.

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 를 참고하고 있어서 어떠한 다른점이 있는지도 질문드립니다

클린 아키텍처와 헥사고날 아키텍처 모두 개발자가 비즈니스에 집중할 수 있도록 하는 구조인데, 이때 도메인 모델을 풍부한 도메인 모델이 아닌 빈약한 도메인 모델로 가져가고, 트랜잭션 스크립트 패턴을 사용해도, 클린 아키텍처와 헥사고날 아키텍처라고 할 수 있는건가요?