안녕하세요. 교육 내용이 도움이 많이 되어 완강 했습니다.죄송하지만, 혹시 교육에서 사용한 PPT 문서 보내 줄 수 있을까요?협업 할 때 참고하면 많은 도움이 될 것 같습니다.이메일 주소는 mytechnic@gmail.com 입니다.감사합니다.

안녕하세요. 강의 정말 잘 들었습니다. 많은 도움이 되고 있습니다. 다름이 아니고,각 도메인모델을 도출하고 난 후, 경우에 따라 여러 모델을 일관성 있게 업데이트해야하는 경우 유스케이스(서비스)를 이용하게 되는데요. 유스케이스의 디자인은 어느 시점에 어떻게 해야하는지 궁금합니다. 강의내용에서는 모델(entity)만을 도출하고 난 후, 패턴을 언급하며 마무리하고 있어서,실질적으로 구현을 위한 유스케이스 디자인 단계가 빠져 있는거 같아서요. 감사합니다! 

대여 모델링 강의에서 RentalItem<VO>에서 overdued, overdueStartDate라는 맴버 변수가 있는데요. 혹시 이걸 반납 예정일을 나타내는 dueDate로 바꾸면 어떨까요? 이러면 ReturnItem<VO>에 RentalItem<VO>를 추가할 때 바로 추가할 수 있을거 같고, 반납 예정일을 연장한다고 했을 때 유연하게 대응할 수 있을것 같습니다.좋은 강의 감사합니다. ^^

안녕하세요 선생님,자세한 도메인 기술은 어렵다고 생각해서 간략하게 상황을 가정하겠습니다.기존에 있던 애그리거트는 한 뭉탱이로 돌아다녔는데기획이 변경되어 스토밍으로 추출했던 기존 애그리거트 루트와 VO 객체가 서로 생명주기가 다른 상황이 되었습니다.루트가 VO를 리스트로 가지고 있으며 루트가 생성되고 특정 이벤트 후에 VO가 생성되어 루트에 추가되고 일정시간이 지나면 VO를 업데이트 해야 하는 상황입니다.VO가 불변객체라 리스트에서 새로운 객체로 갈아치우 것도 아닌 거 같아서,, 현재 억지로 갈아치우게끔 만들어 놓긴 했습니다,,또, 아무리봐도 서로 생명주기가 달라 VO를 다른 애그리거트로 전환하려고 하는데제가 애그리거트들을 수정하는데 있어 근거가 부족하거나, 놓치는 부분이 있을까요?

강사님.도메인 이벤트 추출관련해서 여쭤보고 싶은 부분이 있는데 하기와 같이 단순히 "영화가 예매됨"이 아닌 "상영중인 영화가 예매됨"과 같이 구체적으로 추출해도 상관이 없는것인지 궁금합니다!예를들어 "상영중인 영화가 예매됨"같은 경우에는 커맨드를 추출할 때, 조금 표현하는게 애매한거 같아서요... 이렇게 구체적인 표현보다는 좀 더 추상적으로 표현하는게 좋을까요 ?

안녕하세요!해당 글과 관련되어 의문이 생겨 질문을 남기고 싶습니다. 해당 글에서 처럼 영속성 계층의 엔티티와 도메인 계층의 엔티티를 나누어 사용하는 상황에서, 데이터 변경의 처리에 관해 질문드립니다.우선 Layer를 다음과 같이 구분하였습니다.PresentationApplication DomainInfrastructure(Persistence) 간단하게 Member(Domain Layer)와, MemberJpaEntity(Infrastructure Layer)로 예시를 들어 의문을 가지는 상황에 대해서 말씀드리려 합니다. 이때 규칙을 Application Layer에서 Domain Layer만을 의존한다고 하였을 때, 다음과 같이 Member를 update하는 코드를 작성해야 한다 했을 때 아래와 같이 변경 감지를 사용할 수 없어 save를 재호출해야만 할 것 같은데, 이러한 경우 다른 방법이 있을까요?@Service @Transactional public MemberService { private final MemberRepository memberRepository; // 생성자 생략 public void update(Long id. String name) { Member member = memberRepository.findById(id); member.update(name); // 변경 감지 X -> Member는 Jpa의 @Entity가 아니기 때문 memberRepository.save(member); // 업데이트 하기 위해서는 필요함 } }@Repository @Transactional public MemberRepositoryImpl implement MemberRepository { private final MemberJpaRepository memberJpaRepository; // 생성자 생략 public Member findById(Long id) { MemberJpaEntity entity = memberJpaRepository.findById(id).orElse(null); return Mapper.toDomainEntity(entity); } public void save(Member member) { MemberJpaEntity entity = Mapper.toPersistenceEntity(member); memberJpaRepository.save(entity); } }      

강사님.Controller에 사용자의 요청이 캡슐화되어 전달되어지면서 실제 요청하는 URL과 매핑되어있는 처리 메소드가 호출되는 구조로 알고있습니다!따라서, Controller는 핸들러와 비슷한 개념인거 같은데...어째서 표현 계층에 속하는 것인지요 ?컨트롤러가 사용자의 요청을 전달받기 때문일까요 ? 

안녕하세요 강의를 보던 도중 질문이 생겼습니다. 보통 JPA 서비스 설계시 모놀로틱한 서비스에서 서로 다른 엔티티를 연관관계를 통해 데이터베이스 JOIN 을 이용하여 서비스 하는것으로 알고 있습니다. 그러나 MSA 환경에서는 데이터베이스 자체가 분리되어 있는 상태여서 해당 방식은 불가능 하다는 것을 이전 여러 질문들을 통해 알게 되었습니다.이러한 점을 해결할 방식을 찾는 도중 DDD를 이용하여 관점을 분리하고 연관된 엔티티들을 묶어 Aggregator 개념으로 묶어서 사용한다는 글들을 알게 되었습니다. 여기서 질문인 점은 Aggregator로 연관된 엔티티를 묶는 다는 의미가하나의 마이크로 서비스에 여러 엔티티를 두어 기존 사용하던 JPA 연관관계처럼 사용한다는 것인지아니면 분리된 두 서비스는 각자 두고 상위 서비스를 다시 선언하여 해당 서비스에서 연관된 두 엔티티를 조회하여 묶어서 사용하는 것인지 궁금합니다. 아니면 제가 아예 Aggregator 라는 개념을 잘못 이해한 것일까요?

  안녕하세요.   JPA를 사용해서 엔티티 매핑할 때 DDD에서 말하는 엔티티, 즉 도메인 객체를 바로 매핑하시나요? 아니면 JPA 엔티티를 도메인 객체와는 별개로 만들어서 매핑하시나요?   예제로 가르쳐주시는 건 바로 매핑하시는데, 혹시 실무에선 또 다른지 궁금해서 질문 드립니다.

안녕하세요. 공부하는 개발자입니다.   도메인 주도 설계를 바탕으로 설계를 해보려고 하는 도중에 궁금한것이 있어 질문 드립니다.   데이터를 영속화하기 위해 사용하는 ORM Entity를 하나의 도메인으로 바라보고 설계를하니 너무 관계형 데이터베이스 모델링에 의존적인 설계가 되어버리는것 같습니다. 마치 도메인 주도 설계가 아니라 ERD 주도 설계를 하는 느낌이 듭니다. 도메인 주도 설계에서 말하는 Domain과 데이터를 영속화하기 위해 사용하는 ORM(JPA)Entity를 분리하여 ORM Entity는 RDB 의 모델링에 맞게 설계하여 데이터베이스와의 작업을 수행하고, 실제 핵심 비즈니스 로직들은 ORM Entity가 아니라 POJO로 만들 어진 Domain이 수행하는게 좀 더 DDD에 맞는 개발이 아닌가 하는 생각이 듭니다.   영한님의 생각은 어떠한지, 실무에서는 어떤식으로 설계를 하는지 궁금해서 질문 남깁니다.   감사합니다.    

=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]여기에 질문 내용을 남겨주세요.   안녕하세요   기존에 nosql위주로 개발을 하다가 mysql 및 JPA를 도입하려고하는 영한님 강의 듣고 있는 개발자입니다.     ddd와 연관지어서 jpa의 엔티티 정책에 궁금한 점이 2가지 있는데 (유사한 카테고리)     1. Team 에그리거트와 Member 에그리거트는 간의 경계가 허물어 지는 문제   예를들어서   @Entity class MemberEntity { ... @ManyToOne Team team; ...   }   이런식으로 엔티티가 구성 하시던데요   에릭에반스인지 반버논 책인지 기억은 안나는데 Team을 직접 가지기보다는 String team_id;값을 가지는 것이 권장된다고 알고 있고 저는 실무에서 그렇게 사용하고 있었습니다. 제가 업무에서 mysql를 사용하지 않아서 실제 mysql jpa 사용하시는 분들도 실전에서 위처럼 그대로 사용하는지 궁금하네요.   JPA식으로 사용하게되면, MemberRepository에서 member 를 조회하면 , TeamRepository를 조회하지 않고도 팀 정보를 가져오게 되는 것인데, 이러면 바운디드 컨텍스가 무너지는 결과를 초래하지 않나 싶습니다.   이부분에 대해서 영한님 의견은 어떠신가요?     2. Entity의 오염   JPA를 쓰다보면 @ManyToOne, Load 정책 등 같은 비즈니스 로직과 무관한 DB종속적인 값들이 Entity에 들어가게되더라고요 DDD에서 말하는 순수 핵심 비즈니스 로직의 Entity만 넣고 쓰고 싶은데, JPA를 활용하게 되면 이게 힘든 부분이죠?   JPA Entity를 흔히말하는 DAO처럼 쓰고 별도의 Domain Entity를 만들고 싶은데 이렇게 가능한지 궁금합니다. 대충 JPA내용을 봤을때 이렇게 분리하는게 불가능한 것 같기는한데   실제로 Entity를 어떻게 사용중이신지 궁금합니다.    

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]여기에 질문 내용을 남겨주세요.   회원 도메인 설계 강의를 듣고 궁금한 점이 생겼습니다 아래의 1~5번의 제가 쓴 답변 각각에 대해서 YES/NO인지 궁금합니다. 제가 영어를 못해서 검색한 결과를 제대로 해석했는지 모르겠습니다. 맞는지 확인 부탁드립니다.     1. 도메인 설계가 무엇인가 -> 어플리케이션을 로지컬한 단위로 나누어 각각 설계하는 것이다. 질문게시판에 이미 동일한 질문이 있었고 위키피디아에서 도메인이라는 부분을 읽었습니다(해답은 얻었으나 내용은 생략) 여기서 '요구사항 분석'이라는 두 번째 키워드를 얻었습니다. 2.  요구사항 분석은 무엇인가 -> 소프트웨어 개발 방법 모델 중 '폭포수 모델'의 첫 번째 단계이다. 3. 그럼 강의에서 폭포수 모델을 사용하는 것인가 -> 아니다. 자세히 찾아보니 요구사항 분석은 소프트웨어 개발모델 중 어떤 것이든 다 포함되는 부분입니다. 게다가, 폭포수 모델은 굉장히 오래된 방법이고 요즘은 애자일에 기반한 방법론을 사용한다라는 글을 읽어서 이건 아니라고 판단했습니다. 여기서 '애자일에 기반한 방법론'이라는 키워드를 얻었습니다. 4. 방법론에는 무엇이 있고 이 중 강의에 나온 방법론은 대체 무엇인가 -> DDD일 것이다. 강의에 제시된 그림은 UML이라고 하는 것입니다. 소프트웨어 개발 방법론이라고 검색을 해서 XP, 스크럼, RUP, DDD 이 네 가지를 찾았는데 강의에 나온 그림과 비슷한 UML그림이 등장하는 건 RUP개발 단계 중, Elaboration단계 그리고 DDD의 도메인 레이어 설계부분이었습니다. RUP는 OOA이고 DDD는 도메인 주도 설계인데 이 둘 중 이름부터가 도메인이 들어가는 DDD가 맞을 것이다. 5. 그럼 스프링 강의를 다 듣고 내 어플리케이션을 직접 만드는 단계가 오면 DDD를 공부하면 되는것인가? -> 그렇다 웹 어플리케이션을 만들 때 트랜잭션 스크립트 패턴, 도메인 모델 패턴 이 두 가지 중 하나를 사용한다? 도메인 모델 패턴이 주로 사용된다? 그래서 DDD책을 구해서 읽으면 될 것이다? 소프트웨어 공학과목을 공부해야 할 것이다? 이틀동안 영어를 너무 많이 읽었더니 머리가 혼란스럽다?   저 전자과라서 주변에 펌웨어 개발자밖에 없는데 다들 헛소리 하지 말라 그러고 답을 안줘서 너무 슬픕니다. 누구든 좋으니 대답해주세요. 이틀동안 검색도 많이하고 유튜브 영상도 많이 봤는데 아직도 모르겠습니다. 뭐라고 검색해야 하는지 키워드도 몰라서 이것저것 싹다 검색했습니다. 컴공에서 배우는 소프트웨어 공학과목에 나오는 개념인 것 같은데 그걸 배워야 하나요. 아~정말 야속한 세상 왜 하필 전자과를 들어가가지고 증말.   긴 글 읽어주셔서 감사합니다.

최범균님의 DDD start 로 입문하고 설계에 대해서 요즘 많이 고민하고 있는데요. JPA 를 쓰는 입장에서 boundary context 즉 경계처리를 어떻게 해야하는지 고민입니다. 예를들어 Member, Order Entity 가 있고 Order 의 boundary context 는 Orderer 가 되는데 Orderer (id, name) 를 포함하고 있습니다. 만약 주문정보를 저장하게되면 Orderer 로 인해 Member 의 id 와 name 이 저장되고 이렇게 되면 Member 값이 바뀔시 name 이 달라지는 데이터 무결성이 발생한다고 생각합니다. 그럼 Orderer 처리를 어떻게 하면 좋을까요? 너무 두서없는 질문인데 어떻게 더 표현해야 할지 잘 생각이 안나네요 ㅜ

안녕하세요. 이번 강의 내용에서 추가적인 요구사항을 적용해보는 중, 설계상 궁금증이 생겨 질문하게 되었습니다. jpashop에서는 환불제도 악용 회원의 주문을 일정 기간동안 금지할 수 있다는 요구사항을 추가했습니다. 이 변경된 요구사항을 위해, MemberStatus라는 VO를 Member 클래스에 추가했습니다.  결과적으로, Order 클래스를 생성함에 있어서 MemberStatus의 로직(다른 애그리거트의 Value Object)을 필요로 합니다. 이 때, 선택할 수 있는 생성 방식이 여러개가 떠올라서, 이들의 선택 기준에 대한 조언을 듣고 싶습니다. 첫번째 방식. 정적 팩토리 메서드의 매개변수로 추가 첫번째 방식은 생성시 필요한 정보를 가진 객체(MemberStatus)들을, 정적 팩토리 메서드의 매개변수로 전달합니다. 선택 기준은  객체(Order)를 생성함에 있어서, 특정 객체(MemberStatus)가 필요함을 명시적으로 알릴 수 있습니다. 생성로직을 해당 클래스가 전적으로 제어하는 것이 생성 로직을 한 곳에 더 응집시킬 수 있습니다. 이 두가지를 고려했습니다. 이 방식에서는 회원 차단에 따른동작 분기는 정적 팩토리 메서드 내에서 이루어집니다. 다만, Order를 생성하는데 있어서 MemberStatus 이외에도 협력해야 할 애그리거트들이 많이 존재하는 경우 Order 클래스가 너무 많은 의존성을 가지게 될 수 있다는 점이 우려됩니다. 두번째 방식. 생성을 위한 정보/로직을 가지고 있는 클래스가 생성을 담당 선택 기준은  Member가 Order를 생성하기 위한 로직(회원 차단 여부)을 제공합니다. 위 내용을 고려했습니다. 이 방식에서는 검증 통과 여부에 따른 동작 분기는 Member의 메서드 내에서 이루어집니다. 다만, 이 방식은 Member —> Order로의 불필요한 의존성을 만들어낼 수 있다고 우려했습니다 특히, 생성에 대한 책임을 맡는다는 것은 내부에 어떤 데이터를 가지고 있는지 전부 알아야 한다는 점에서 생각보다 과도한 의존성을 부여하고 있는 것 같습니다. 또한 협력해야 할 애그리거트가 많아질 수록, Member가 생성과 관련된 다른 클래스들에 대한 많은 의존성을 감당해야 한다는 점이 우려됩니다. 세번째 방식. 애그리거트를 생성하는 Domain Service를 만든다. 선택기준은 많은 의존성을 가져야 하는 생성 로직을 서비스에 담음으로서, 엔티티가 불필요한 의존성을 가지는 것을 방지합니다. 위 내용을 고려했습니다. 다만, 조금만 복잡해져도 도메인 서비스를 사용하고자 하는 유혹이 생겨서, 자칫하면 다른 로직들도 Domain Service로 구현해, Entity 자체의 응집성이 작아지는게 아닌가 우려스럽습니다. 질문 내용 정리 1. 각 생성 방식을 선택함에 있어서 미흡한 선택 기준에 대해서 조언 해주 실 수 있나요? 2. 또 첫번째, 두번째 방식이 우려하는 사항들은 현재의 사례에서는 잘 드러나지 않는 '잠정적인' 우려사항들인데, 실제로 이 우려사항들이 나타나기 전까지는 가장 간단한 구현(첫번째 혹은 두번째)을 그대로 사용해도 될까요?

안녕하세요 영한선생님! 훌륭한 강의와 친절한 피드백 항상 감사합니다. 강의 자체가 너무 완벽해서 강의 내용을 잘 이해했다고 생각했는데 개인프로젝트를 진행하며 강의와 연관된 응용적인 내용에서 막히는 부분이 있어 질문드립니다!! 답변해주시길 부탁드리겠습니다! 현재 회원가입 양식에서 유저의 이메일과 비밀번호, 프로필사진을 입력받고 있습니다. 클라이언트에서 텍스트와 이미지를 동시에 전송하는 multipartform방식을 사용했습니다. 그래서 데이터를 받을 때도 MultipartHttpservletRequest로 받았습니다! 이제 서비스계층에서 처리하는 작업은 도메인에게 dto를 전달해 적절히 초기화된 Member를 요청하고 그 Member가 중복이메일을 가졌는지 체크한 뒤  MemberRepository에 저장하는 형식으로 코드를 짰습니다. 이때 Member생성 시 필요한 작업인 프로필 이미지를 aws s3에 넣고 url을 저장하는 부분과  비밀번호를 인코딩하는 작업은 제  판단으로 도메인인 Member에게 맡기는 게 맞겠다 싶었습니다. 다만, Member는 스프링컨테이너의 관리는 받지 않아 스프링빈인 awsS3Service와 passwordEncoder의  의존성 주입을 받지 못했습니다.  그래서 파라미터로 전달해 작업을 처리했습니다! 결국 이런 파라미터의 전달방식은 유지보수성을 떨어뜨리는 것 같습니다. awsS3Service를 추상화한 인터페이스를 정의하는 방법이 떠오르긴 하지만  결국 파라미터 전달이라는 부분이 계속 찝찝합니다 ㅠㅠ 그렇다고 MemberService에서 Member의 setter를 열어 수정하자니 이것도 임시방편인 것 같습니다. 이러한 문제의 최적화된 해결방법이 있을까요?? 애초에  multipartform으로 입력받는 게 안 좋은 방법일까요? 데이터를 따로따로 받아서 처리하는 게 현업에서 자주 쓰이는 방법일까요?? 강의 내용과 직접적인 연관이 없는 내용의 질문이어서 죄송합니다 ㅠㅠ 객체지향을 고려한 예제를 찾는 게 쉽지않아 결국 선생님께 질문드리러 왔습니다. 작은 힌트라도 주시면 감사하겠습니다!!