han jeong heon

안녕하세요 강의자입니다. 정리하면 다음과 같습니다. (AI를 통해 정리했습니다.^ ^)<hr><h2 style="text-align: left">핵심부터</h2>👉둘은 같은 Aggregate인데, 목적이 다르다<hr><h2 style="text-align: left">1⃣ DDD에서 Aggregate (설계 관점)</h2><ul><li>객체들을 하나로 묶은 일관성 단위</li><li>규칙을 지키는 경계</li><li>반드시 Root를 통해서만 접근</li></ul>👉 질문 기준 “어디까지를 한 덩어리로 묶어야 안전한가?”<hr><h2 style="text-align: left">2⃣ 이벤트 스토밍에서 Aggregate (흐름 관점)</h2><ul><li>Command를 받아서</li><li>검증하고</li><li>Event를 만드는 책임 주체</li></ul>👉 질문 기준 “이 이벤트를 누가 발생시키는가?”<hr><h2 style="text-align: left">3⃣ 차이를 한 번에 보면</h2><h3 style="text-align: left">이벤트 스토밍</h3><ul><li>주문하기 → Order → 주문됨 👉 Order = 명령 처리 주체</li></ul><h3 style="text-align: left">DDD 설계</h3><ul><li>Order 안에 OrderLine 있음</li><li>총액 계산, 취소 조건 있음 👉 Order = 데이터 + 규칙 묶음</li></ul><hr><h2 style="text-align: left">5⃣ 핵심 정리 </h2>👉 이벤트 스토밍의 Aggregate는 “이 일을 누가 책임지냐”👉 DDD의 Aggregate는 “그 책임을 어떻게 구조로 묶냐”<hr><h2 style="text-align: left">6⃣ 전체적으로 정리하면</h2>👉이벤트 스토밍은 Aggregate 후보를 찾는 단계, DDD는 그걸 정확히 설계하는 단계라고 생각하시면 됩니다.

애그리거트 질문있습니다!

네 강의자입니다. 하나하나 답변드리면,<ol><li>db를 나누면 조인이 깨지나?</li></ol>네. 서비스가 각각 DB를 가지면(독립 DB) 기본적으로 DB 레벨 JOIN은 못 합니다. 그래서 MSA에서는 보통 이렇게 바꿉니다.(A) 조회 JOIN → “API 조합(Composition)”<ul><li>화면/조회가 필요하면<ul><li>BFF/조회용 API가 여러 서비스에서 데이터를 가져와 애플리케이션에서 합쳐서 내려줌</li></ul></li><li>단점: 호출이 여러 번(네트워크 비용), 성능/장애 전파 고려 필요</li></ul>(B) 조회 JOIN → “읽기 전용 모델(Projection) / CQRS”<ul><li>자주 쓰는 조회는<ul><li>이벤트/동기화로 읽기 전용 테이블을 따로 만들어서</li><li>거기서는 JOIN이 가능하게 만듦</li></ul></li><li>실무에서 제일 흔한 해법 중 하나</li></ul><ol start="2"><li>그럼 JOIN 하다가 DB 나뉘면 쿼리 효율 떨어지나요?”</li></ol>그럴 수 있어요. 특히 “모노리스에서 SQL JOIN 한 방”이던 걸 MSA에서 “서비스 3개 호출 + 조합”으로 바꾸면 지연이 늘 수 있습니다.그래서 전환 시 판단 기준을 이렇게 잡으면 됩니다.JOIN이 많은데도 MSA로 가야 하는 경우<ul><li>팀/배포/확장/장애 격리가 더 중요할 때</li><li>도메인이 커져서 변경 영향도가 너무 클 때</li></ul>JOIN이 너무 핵심이고 실시간/고성능이 절대 조건이면<ul><li>무리하게 쪼개지 않거나</li><li>쪼개더라도 조회는 별도 읽기 모델로 풀어야 합니다(CQRS/Projection)</li></ul><ol start="3"><li>데이터 레이크 만들 타이밍? </li></ol>네, 바로 데이터레이크로 가는 건 아닙니다. 보통은 CQRS, 머터리얼라이즈드 뷰, 읽기 전용 조회 서비스를 먼저 고려하고, 그걸로 감당이 안 될 만큼 데이터 양·조회 복잡도·분석 요구가 커질 때 데이터레이크(DWH/레이크하우스)로 가는 게 일반적인 순서입니다.감사합니다.

MSA 질문이 있습니다

네 강의자입니다. 아래 답변처럼, 기업의 비지니스 전략,성격 변화나, 조직구성원의 역량이 성장에 따라 도메인 유형은 변경될 수 있습니다. 도메인의 depth에 대해 말씀 주셨는데, 아마도 업무분해의 대중소 depth를 애길하시는 듯 합니다. 아마도 도메인 주도 설계시 문제영역으로 제시되는 도메인이 계층형인 듯 해 보이네요. 우선 서비스 성장에 따라 변화 할 수 있다는 답변을 드리고, 구체적 예시를 들어 주시면 더 상세한 답변을 드릴 수 있을 것 같습니다.

도메인 질문있습니다

좋은 피드백 감사합니다! 말씀하신 대로 강의에서 다뤘던 Event Storming 기반의 도메인 분리 방식은 지금도 여전히 잘 쓰이고 있습니다. 다만 실무를 하면서 조금 더 구체적인 기준과 감이 쌓여서, 예전보다 정교하게 다듬어진 부분이 있어요.<hr><h3 style="text-align: left">1⃣ 중심은 여전히 “Event Storming”</h3>핵심은 여전히 ubiquitous language 로 이벤트 흐름을 파악하는 거예요. 다만 예전보다 이벤트 간 경계(boundary) 를 정할 때 좀 더 명확한 기준을 씁니다.<ul><li>단순히 “업무적으로 의미 있는 이벤트”가 아니라 → “동기와 결과가 완결되는 최소 단위”를 하나의 서브도메인으로 봅니다. 이렇게 하면 나중에 마이크로서비스로 전환할 때 트랜잭션이나 데이터 일관성 관리가 훨씬 자연스러워집니다.</li></ul><hr><h3 style="text-align: left">2⃣ Context Mapping에 추가된 관점</h3>과거에는 업무 흐름 중심의 경계를 봤다면, 지금은 여기에 “데이터 소유권”과 “변경 주기” 도 같이 봅니다.즉 예전에는 '이벤트 플로우 중심'이었다면 현재는 '이벤트 + 데이터 소유권 + 변경 주기' 도 살펴서 도메인 간 결합도 최소화하려고 하고 있습니다.이렇게 보면 업무적으로 분리돼 있어도 데이터가 너무 강하게 묶여 있는 영역을 초기에 구분하기 쉬워요.<hr><h3 style="text-align: left">3⃣ “Domain Canvas” 병행</h3>요즘은 Event Storming 이후 각 도메인을 Domain Canvas 형태로 구체화합니다. 즉,<ul><li>도메인의 목적</li><li>주요 액터 / 유즈케이스</li><li>대표 엔티티</li><li>외부 연동 포인트</li><li>팀 책임(ownership)</li></ul>을 한 장에 정리해서 도메인 단위의 책임과 협력 관계를 명확히 해두죠.이 정도로 답변 드릴 수 있겠네요. 감사합니다.

현재에도 강의와 동일한 방식을 사용하고 계실지 궁금합니다.

안녕하세요 강의자 한정헌입니다. 답변드리면<h2 style="text-align: left">1. 강의에서 <code>model</code>을 사용한 이유</h2><ul><li>강의에서는 두가지를 분리하여 구조를 잡으면 아무래도 복잡해 지고, 핵심 개념 전달이 어렵기 때문에 model 에 JPA 매핑을 했습니다.</li><li>실제로는 위에 AI가 답변한 것처럼 Hexagonal Architecture에서 domain model과 persistence entity는 서로 다른 책임을 가지므로 분리하는 게 맞습니다.</li><li>다만 실무에서도 이는 비지니스 또는 마이크로서비스 성격에 따라, 엄격하게 헥사고널 아키텍처를 준수할 수 있고, 어느정도 모델 내부에 or mapping를 함께 하는 타협을 진행할 수도 있을 것 같습니다.</li></ul><h2 style="text-align: left">2. 헥사고널 아키텍척에서의 일반적인 구성</h2><ul><li>엄격하게 준수하려고 한다면 보통 아래와 같이 패키지를 나누어 관리합니다.&nbsp;</li></ul><pre><code>framework
 └── jpaadapter
 └── entity ← JPA Entity 클래스들 위치
domain
 └── model ← 순수 비즈니스 모델 (애그리게이트 루트, VO 등)
</code></pre><h2 style="text-align: left">3. 관계와 역할 구분</h2>&nbsp;이렇게 구분 했을 때 책임 및 특징은 다음과 같아요.<ul><li><code>domain.model :</code>비즈니스 규칙과 도메인 로직 . JPA, Spring 등 외부 기술 의존 없음</li><li><code>jpaadapter.entity :</code>DB 매핑 전용 클래스 , @Entity, @Table 등 JPA Annotation 사용</li><li>두 계층은 Mapper를 통해 연결합니다.<ul><li><code>Entity </code>↔<code> Domain Model</code> 변환 코드가 이 계층에서 담당됩니다.</li></ul></li><li>이렇게 하면 도메인은 프레임워크에 독립적으로 유지되고, JPA 교체나 다른 persistence 전략 도입 시 영향이 최소화됩니다.</li></ul>답변이 되었으면 좋겠습니다. 감사합니다. ^ ^

강의보다 바로 여쭤봅니다.

안녕하세요 강의자 한정헌입니다.domain을 구현할때 이런 중첩 계층화된 모델은 도메인 모델에서 바람직한 구조는 아닌 것 같네요.즉 도메인 모델의 한 단위가 되는 어그리게이트를 모델링 할때, 여러개의 중첩적인 엔티티를 최대한 가지지 않게 설계해야 합니다.(어그리게이트 에는 개인적으로 한개 정도의 엔티티 설계가 적정하다 생각합니다.)그런 구조를 피하기 위해 다음과 같이 진행합니다. <h4>1. Aggregate Root 기준으로 설계</h4><ul><li>DDD에서는 한 Aggregate Root(Aggregate의 최상위 엔티티)에서 다른 Aggregate Root를 직접 참조하지 않도록 권장합니다.</li><li>즉, <code>A -> B -> C</code> 형태가 아니라 <code>A</code>가 <code>B</code>의 ID만 갖고, <code>B</code>가 <code>C</code>의 ID만 가지도록 설계하는 것이 일반적입니다.</li></ul><h4>2. Lazy Loading을 도메인 레이어에서 직접 구현</h4><ul><li>JPA의 Lazy Loading을 사용하지 않는다면, 직접 데이터를 가져오는 방식으로 구현할 수 있습니다.</li><li>예를 들어, <code>A</code>에서 <code>B</code>를 가져올 때, <code>B</code>의 리스트를 로딩하는 것이 아니라 <code>BRepository</code>를 통해 필요할 때 조회하도록 만들 수 있습니다.</li></ul><pre><code class="language-java">class A {
 private List<Long> bIds; // ID만 저장
 
 public List getBs(BRepository bRepository) {
 return bRepository.findAllByIds(bIds);
 }
}
</code></pre><ul><li>이렇게 하면 <code>A</code>가 <code>B</code>를 직접 포함하지 않고 ID만 저장하여 필요할 때만 데이터를 가져올 수 있습니다. </li></ul>답변이 되었기를 바라며, 감사합니다.

Aggregate 하위에 꼬리를 무는 Entity 는?

안녕하세요. 강의자 한정헌입니다.헥사고널 아키텍처는 포트 엔 어댑터 패턴을 제안한 alistair cockburn를 기반으로 다양한 형태의 모습으로 소개되고 있습니다.언급하신 모델은 인터넷에 일반적으로 많이 퍼져 있으나 소프트웨어 아키텍처가 다양한 변종이 있고 상황에 따라 여러 모델이 있을 수 있다 생각합니다.제가 강의 시 참고한 모델은 다비 비에이라의 '헥사고날 아키텍처 설계와 구현'이라는 서적의 모델입니다.헥사고널 아키텍처 모델을 3개의 헥사고널(도메인,애플리케이션,프레임워크)로 나누고 각각의 의미를 부여했는데 애플리케이션 헥사곤의 요소를 유스케이스-인풋포트-아웃풋포트로 구현하고 유스케이스를 인터페이스로 정의하고 인풋포트를 구현체로 활용했습니다.다비 비에이라의 방식은 유스케이스를 단순한 구현체의 역할 보다는이바 야콘슨의 '유스케이스 시나리오, '유스케이스 명세' 의 개념으로 파악한 것으로 애플리케이션 헥사곤이 갖는 의미 즉 '시스템이 정의 한 목표를 달성하기 위해 함께 동작하는 일련의 행위의 집합'를 구현한다. 를 강조하기 위해 유스케이스로 이러한 애플리케이션이 제공할 기능(일련의 행위 집합으로 시나리오 형태임)를 먼저 인터페이스로 정의한 것이라 생각합니다.즉 간단히 말하면, 애플리케이션 헥사곤에서 가장 중요한 것은 도메인 헥사곤이 가진 비지니스 여러 개념을 복합적으로 활용하여 비지니스 목적에 맞는 시나리오를 구현하는 것인데, 그걸 명확히 표현한 방식이 이바 야콥슨 '유스케이스 명세'라는 방식이고, 이것을 강조한 구조라고 생각하면 됩니다.저는 이 방식이 헥사고널 아키텍처 모델에 '유스케이스' 라는 개념을 설명하는데 타당 하다고 생각하여 이 방식으로 강의를 구성하였습니다.물론 Management Uiti님이 제시하신 구조로 헥사고널 아키텍처 구조를 잡아도 타당하다고 생각합니다. Management Uiti님이 제시하신 구조는 비지니스와 기술을 어떻게 분리하여 어떻게 유연하게 할 것 인가? 에 초점을 맞췄다면 , 비에이라의 헥사고널 아키텍처는 한 발 더 나아가 그렇다면 비지니스 개념 과 활동을 어떻게 구조화 할 것인가를 좀 더 생각한 결과라 판단됩니다.답변이 되었기를 바라며 감사합니다.

헥사곤 아키텍쳐 관련하여 문의드립니다.

강의자입니다.^ ^ AI가 이미 답변을 드렸네요. AI 가 말한바와 같이 API,이벤트기반 통신,데이터 복제로 해결할 수 있으며, 의외로 백엔드 서비스간의 연관관계보다는 프론트엔드 단의 정보를 가져갈 수도 있습니다.예를 들면 대여서비스가 필요한 도서정보와 사용자정보를 프론트에 이미 조회된 정보를 가져갈 수 있습니다. 물론 백엔드 대여 서비스에서 실제 사용자가 존재하는지? 와 도서가 대여가능한지에 대한 검증은 필요합니다.이후 강의를 더 듣다 보시면 더 깊은 이해가 가능하실 것이라 판단됩니다. 감사합니다.

다른 BC 또는 마이크로서비스 담당 정보를 어떻게 이용하나요?

강의자 한정헌입니다.답변드리면 도메인 주도 설계에서 vo를 설계할 때 불변성을 유지하는 것이 매우 중요한 원칙 중 하나입니다. 따라서 <code>private final</code>로 필드를 선언하여 vo 내부 상태가 변경되지 않게 안전하게 함 좋은 설계 방법입니다. 하지만 이렇게 하면 내부에서 사용하는 객체,List,Map등이 있다면 이 또한 모두 불변으로 유지해야 하고 외부 객체 연동 시 불변성을 유지하는 코드 작성 등 객체 내부의 복잡성이 증가하고 추가 적인 처리 코드 작업이 필요합니다. 따라서 불변성을 유지하는 것의 중요성과 그것을 유지하기 위한 복잡성 추가 등을 트레이드 오프 할 필요성이 있습니다.본 강의에서는 이러한 점을 고려하여 ,특히 가독성 측면에서 final처리하지 않는 것이 좋다고 생각했습니다. 그리고 rentalItem 은 이전 모델링 강의 에서 VO 로 선언했으나 overDued의 값이 변경됨으로 불변성을 잃음으로서 엔티티로 다시 개념 정의 한 부분입니다. 그런데 엔티티임에도 @Entity 처리를 안 한점을 지적 주셨는데 JPA의 <code>@Entity</code>와 도메인 주도 설계(DDD, Domain-Driven Design)에서의 엔티티(Entity)는 서로 다른 맥락에서 사용되는 개념입니다. 두 개념 모두 "엔티티"라는 용어를 사용하지만, 목적과 초점이 다릅니다.<ul><li>DDD의 엔티티 <ul><li>상태와 동작 : 데이터뿐만 아니라 행위(메서드)를 포함</li><li>식별성(식별자을 기준으로 동일성 판단)&nbsp;</li></ul></li><li>JPA의 엔티티<ul><li>데이터베이스와 동기화의 목적</li><li>데이터베이스 테이블과 매핑됨을 의미</li><li>반드시 기본키가 존재해야 함.(@id)</li></ul></li></ul>물론 현실적으로 데이터베이스와 매핑시 JPA의 <code>@Entity</code>와 DDD의 엔티티는 함께 사용되는 경우가 많습니다. 그렇지만 반드시 그래야만 하는 것도 아닙니다.즉 비지니스 로직을 처리하기 위한 도메인 모델링 과 데이터 처리를 하기위한 or매핑과는 전혀 다른 영역이라 생각합니다.따라서 RentalItem의 경우 초기에 도메인 모델링 관점에서 행위가 없기 때문에 vo로 설계했으나 overdued등의 값이 변경되어 불변성이 깨진다 판단하여 엔티티로 개념을 변경한 것이지만 역시 vo의 성격이 강하기 때문에 vo처럼 처리 했다고 생각하시면 될 것 같습니다.

VO 클래스의 불변 필드 선언을 하지 않으신 이유?

tkwoo님 안녕하세요. 강의자입니다.네 지적하신 점이 맞습니다. 제가 코드의 결함을 인지하고 제공하는 소스코드에는 이후 변경하였는데, 동영상 상에는 공지를 제대로 하지 못했네요. 죄송합니다. 다시 확인해서 공지를 하도록 하겠습니다. 지적 감사합니다.

han jeong heon

投稿