어떻게 보면 클린 아키텍처와 헥사고날 아키텍처도 스프링 처럼 개발자에기 비즈니스에 집중할 수 있도록 도와주는 것 같은데 맞을까요?

안녕하세요. 질문이 많네요. 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곳에서 사용하시는지 이유가 궁금합니다! 

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요.도메인모델을 만들때 Entity와 VO는 단순히 불변성을 가지고 구분하는 것인지요?그리고 JPA에서의 Entity와는 다른 개념인지 궁금합니다.감사합니다.

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요! 좋은 강의 감사드립니다 ㅎㅎ (강의에서 나온대로 패키지와 클래스를 구성한 상태입니다.) 혹시 DTO를 framework 패키지에 넣는 이유가 있을까요? 저는 개인적으로 UseCase나 InputPort에 framework 패키지에 대한 import가 생기기 때문에 의존성이 생긴다고 판단해 application에 DTO를 생성할 것 같습니다. 혹시 제가 생각하지 못한 다른 이유가 있는지 궁금합니다!

전략적 설계로 문제를 분할 후 전술적 설계로 그 문제영역을 정복하는 느낌으로 이해했는데, 그럼, 전략적 설계가 선결적으로 잘 되어야지 전술적 설계도 잘 될 수 있는건가요?

DDD 공부하면서 느낀 점이 현실적으로 완전한 DDD를 하는 것은 어렵지만 부분적으로도 적용시켜볼 수 있겠다라는 생각이 들었습니다. 예를 들면 전략적 설계는 MSA 로 전환할 때, 전술적 설계는 JPA를 사용할 때 활용해 볼 수 있겠다 싶은데 맞게 이해한 걸까요?

애그리거트를 어느정도의 크기로 만들어야 하는지에 대해 궁금증이 생겨서 질문들입니다. 애그리거트내에 여러 엔티티와 여러 값 객체로 이루어질 수 있으나, 애그리거트는 작은 단위로 만드는게 좋아서,하나의 애그리거트에 여러 엔티티보다 하나의 엔티티로 만드는 것을 추천하시나요? 애그리거트의 크기를 정할 때 강사님의 기준이 있다면 공유해주실 수 있나요? 

엔티티와 값객체와의 차이 중 하나가 값객체는 바운디드 컨텍스트를 옮겨 가더라도, 그 네이밍 그대로 유지할 수 있는 반면, 엔티티는 변경해야할 수도 있다고 생각하는데, 맞을까요?예를 들어, Address(주소, 상세주소, 우편번호 포함)라는 값객체를 만들었을 때, 회원 바운디드 컨텍스트에서 회원의 주소와 주문 바운디드 컨텍스트에서 주문자의 주소의 경우, 다른 점이 없는 반면, User 라는 엔티티는 주문 바운디드 컨테스트에서 주문자이고, 리뷰 바운디드 컨텍스트에서는 리뷰어일 수 있어서, 다를 수 있다고 생각했거든요!

강의 잘 듣고 있습니다!강의 듣고 SNS 프로젝트를 DDD를 적용시켜보려고 하는데,서비스 초기에는 Value Obejct 였던 것이 Entity가 될 수 있고,Entity였던 것이 Aggregate 가 될 수 있는 등 서비스가 커짐에 따라 변경될 수도 있나요?

안녕하세요2일동안 강의 달리면서 실습도 하면서 궁금증을 해소하기위해 달려온 잡부개발자입니다최근 일반 레이어드 아키텍처로만 개발을 진행하니 생긴 문제들(테스트진행이 어려워짐, 소스파악하기 어려워짐 등등)이 생겨서 다른 아키텍처가 있나...찾아보다가 헥사고날 아키텍처가 가장 괜찮았다고 생각했고 DDD 형태로 진행하는게 깔끔할꺼같아서 혼자서 구조를 만들어보았어요아래 설명을 이어붙히도록하겠습니다adapterㄴ 헥사고날중 가장 바깥에 존재하는 controller, dao 부분adapter-modelㄴ adapter 에 쓰이는 모델들을 application 모듈과 연동시키기 위해 만든 model 클래스 모듈 applicationㄴ 각각의 UseCase 구현체와 인터펭이스가 존재하며 adapter-model 을 domain 객체로 변경하는 역할도 가진 모듈 domainㄴ 실제로 비즈니스로직을 가질수있는 POJO 도메인 객체위 구조는 Aggregate 를 적용하지않았기때문에 향후 각각의 작은 서버로 구성할수있는 MSA 로 뺄수있는 구조는 아니에요 다만 그건 aggregate 모듈을 만들어서 빼면 되는거라 생각하는데 그것보다도 가장 궁금한점은..... 비즈니스 로직을 POJO 객체가 있는 domain 모듈로 파싱할때 JPA 기준 A 라는 유저가 가지고있는 게임플레이 히스토리들도 가지고있잖아요? 이건 POJO 객체로 가져올때 히스토리 객체들도 모두 가지고와서 POJO 내에 넣어야하나요?반대의 경우 히스토리에서는 유저객체를 들고있을텐데 이때 의존을 모두 가져와야하나요? 아니면 유저의 키값만 객체로 들고있으면될까요?만약 해당 유저가 한시간에 1000번의 게임을 했다고 가정하면 몇일만 조회해도 엄청 많은 데이터가 램으로 올라가기때문에 좀 부담스러운데 히스토리가 필요한경우 쿼리에 비즈니스로직을 담아 타협해야하나요?물론 드라마틱한 성능차이가 없다면 도메인에서 처리해도되겠지만 성능상 차이가 많이 난다면 쿼리에 비즈니르로직을 담아야하는게 아닌가싶어서요글이 좀 생각의 흐름대로 쓰인거같아 미리 죄송합니다 ㅠ

도메인 서비스와 응용서비스를 구분할 수 있는 조건이 무엇일까요?사내 프로젝트 마다 달랐고, 항상 경계가 모호해서 해당 프로젝트의 정책에 맞추어 개발했는데 이 부분에 대해 의견을 듣고 싶습니다.- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.

논리적인 개념인지 물리적인 개념인지 둘 다 포함하는 영역인지 궁금합니다. Order와 OrderHistory 테이블과 Entity(JPA) 는 분리 되어 있고 같은 트랜잭션에서 처리 한다는 가정하에 (저는 History 성 테이블을 같은 트랜잭션안에 두지 않는 것을 선호합니다) 두개를 동일한 Aggregate 라고 할 수 있나요?  - 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.

안녕하세요. 좋은 강의 감사합니다.섹션 8. 실습 - 마이크로서비스 별 도메인 모델 정의 장에서 궁금점이 생겼는데요.우선 제가 DDD 를 공부하며 이해한 VO 는 특별한 identity 가 존재하지 않는 immutable 한 값을 표현하는 객체로 이해했습니다. 실제로 강의에서도 동일한 내용을 이해할 수 있었어요.하지만 실습 장에서 설계된 RentalItem, LateFee 가 VO 즉, 불변 값 객체와는 거리가 있다고 느껴져서요.RentalItem 에서 "is_overdued: boolean", LateFee 에서 "point: Point" 는 각 addLateFee, removeLateFee, overdueItem operation 에 의해서 값이 변경될 것으로 모델이 확인됩니다.제가 그동안 DDD 를 공부하며 이해했더 내용 중 하나는 Aggregate Pattern 에서 Aggregate 가 되는 것은 Root Entity 로 명명되며 Root Entity 내부에 표현되는 것은 Entity 와 VO 로 학습을 했었는데요. 이러한 RentalItem, LateFee 는 Entity 가 되어야 하는 객체 아닌가 의문이 들어서 질문드려요!좋은 강의 감사합니다 :)

안녕하세요. 김영한 선생님의 강의를 참 잘 보고 있는 학생입니다. SQL 중심적인 개발의 문제점 편에서, 객체지향 프로그래밍에서 객체는 자유롭게 객체 그래프를 탐색할 수 있어야하지만 SQL로 개발하는 경우에는 처음 실행하는 SQL에 따라 탐색 범위가 결정된다는 문제가 있다고 말씀하셨습니다. 그리고 엄격한 도메인 주도 설계의 관점에서는 '도메인 객체'와 '엔티티 객체'를 분리해야 한다고 알고 있습니다. 비즈니스 로직을 다루는 도메인 객체가 JPA라고 하는 기술에 의존하는 것은 영 즐거운 일은 아니기 때문이죠..( https://stackoverflow.com/questions/24703756/having-separate-domain-model-and-persistence-model-in-ddd )그렇기 때문에 도메인 객체와 엔티티 객체를 분리하게 된다면 Repository 계층에서 예를 들어 findById를 했을 경우 엔티티 객체를 도메인 객체로 매핑해서 돌려주어야 합니다. 그런데 이럴 경우, 기존의 SQL로 개발하는 경우와 비슷한 문제가 발생하게 되는 것 같습니다. 매핑을 어디까지해서 돌려주어야 하느냐는 점이죠. Member를 조회했을 때, 객체 그래프 안에 있는 Category까지 싹싹 다 조회해와서 매핑을 해주기도 곤란한 노릇이고, MemberWithTeam, MemberWithOrderAndOrderItem... 와 같은 객체를 따로 따로 만드는 것도 요상해보입니다. 그렇다고 객체 그래프를 다 끊어놓자니 그것도 객체지향적이지 않은 것 같아보이구요.. 이런 상황에서는 어떤 식으로 도메인 객체를 설계하는지, 엔티티 객체의 매핑은 어떤 방법으로 이루어지는지가 너무 궁금합니다.