マイクロサービス設計（EventStorming、DDDを用いて）

같은 도메인이라도 depth에 따라 일반에서 코어로 바뀔 수 있는거 아닌가요?그리고 이게 서비스 운영하면서 바뀔 수 있지 않나요?

안녕하세요msa에서 db를 각자 쓰게되는 패턴이라면 join이 깨지지 않나 하는 생각이 들었습니다.혹시

우선 좋은 강의 정말 잘 들었습니다. 감사합니다. 그동안 파편화되어 있던 "어떻게 도메인을 분리하는가"에 대한 질문이 강의를 토대로 많이 깔끔해질 수 있었습니다.

컨텍스트 매핑 강의를 듣는 중입니다.대여를 처리하려면 도서 정보, 회원 정보도 필요합니다.다른 BC 또는 마이크로서비스가 관리하는 정보를 어떻게 이용하나요?- 대여할 도서(도서 정보 필요)- 대여할 사용자(회원

VO Money 에서 add(money:Money) 함수에 대해서 궁금합니다.</

Entity를 설계 하다가 자주 변하지만 응집도가 높은 값들은 어떻게 해야할까요?자주 변하지만 응집도가 높은 값들은 VO를 사용한다.VO로 선언된 값의 수정은 불가능 하지만 생성으로 값을 초기화 한다.<

특정 비즈니스 문제를 설명하는 거대한 도메인에 서브 도메인으로 핵심, 지원, 범용이 있다는 것은 알겠는데요. 그럼 바운디드 컨텍스트는 각각의 서브 도메인과 1:1로 동등한 관계로 매칭이 되는걸까요?아니면 각각의 서브 도메인 안에 바운디드

앱에서 DDD를 적용해보려고하는데 어려움이 있어 질문드립니다.앱단에서 어플리케이션 레이어의 서비스는 어떻게든 식별해서 진행이되는데어그리게잇, 엔티티, 값 객체에서 막막하게 느껴집니다.막막하게 느껴지는 이유는 결국 데이터를 최종

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

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

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

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

애그리거트를 어느정도의 크기로 만들어야 하는지에 대해 궁금증이 생겨서 질문들입니다. 애그리거트내에 여러 엔티티와 여러 값 객체로 이루어질 수 있으나, 애그리거트는 작은 단위로 만드는게 좋아서,하나의 애그리거트에 여러 엔티티보다 하

엔티티와 값객체와의 차이 중 하나가 값객체는 바운디드 컨텍스트를 옮겨 가더라도, 그 네이밍 그대로 유지할 수 있는 반면, 엔티티는 변경해야할 수도 있다고 생각하는데, 맞을까요?예를 들어, Address(주소, 상세주소, 우편번호 포함)라는 값객체를 만

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

도메인 서비스와 응용서비스를 구분할 수 있는 조건이 무엇일까요?사내 프로젝트 마다 달랐고, 항상 경계가 모호해서 해당 프로젝트의 정책에 맞추어 개발했는데 이 부분에 대해 의견을 듣고 싶습니다.- 학습 관련 질문을 남겨주세요. 상세히 작성하

논리적인 개념인지 물리적인 개념인지 둘 다 포함하는 영역인지 궁금합니다. Order와 OrderHistory 테이블과 Entity(JPA) 는 분리 되어 있고 같은 트랜잭션에서 처리 한다는 가정하에 (저는 History 성 테이블을 같은

안녕하세요. 좋은 강의 감사합니다.섹션 8. 실습 - 마이크로서비스 별 도메인 모델 정의 장에서 궁금점이 생겼는데요.우선 제가 DDD 를 공부하며 이해한 VO 는 특별한 identity 가 존재하지 않는 im

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

안녕하세요. 강의 정말 잘 들었습니다. 많은 도움이 되고 있습니다. 다름이 아니고,각 도메인모델을 도출하고 난 후, 경우에 따라 여러 모델을 일관성 있게 업데이트해야하는 경우 유스케이스(서비스)를 이용하게 되는데요.