유비쿼터스 언어와 class name

Question

안녕하세요! 강의 잘 듣고있습니다. 질문이 두 개 있는데요,

1/ RentalCard라는 도서 대여 카드로 Entity를 구성하셨는데, 이벤트 스토밍때 한 번도 Card라는 개념이 나오지 않은 것 같습니다.

DDD 자체가 유비쿼터스 언어로 기술되어야하는 것으로 이해했는데, Card라는 키워드가 이벤트 스토밍때 도출되지 않는걸로 봐서는 비즈니스 언어라고 하기 어려울 것 같습니다.

이 상황에서 RentalCard라는 네이밍을 지으신 이유가 있을까요?

2/ RentalCard 도메인 자체에 ReturnItem을 쥐고있어, 이 설계에서는 Aggregate가 매번 ReturnItem 리스트를 조회하게 됩니다. 사용자 대여 목록이 쌓이게 되면 이 리스트가 매우 커질수도 있을 것 같은데, 이러한 문제는 현업에서 어떻게 처리하나요?

han jeong heon · Answer

좋은 질문 감사합니다. 두 질문 모두 DDD에서 모델을 어떻게 바라봐야 하는지와 관련된 중요한 부분이라고 생각합니다. 1. RentalCard라는 이름이 이벤트 스토밍에서 나오지 않았는데, 유비쿼터스 언어라고 할 수 있을까요? 말씀하신 부분이 맞습니다. 이벤트 스토밍 과정에서 RentalCard 라는 용어가 도출되지 않았고 실제 현업의 비즈니스 담당자도 사용하지 않는 용어라면, 엄밀하게는 처음부터 유비쿼터스 언어라고 보기는 어렵습니다. 강의에서는 한 사용자의 대여 상태와 대여/반납 규칙을 관리하는 Aggregate 를 표현하기 위해 RentalCard 라는 개념을 모델링 과정에서 추가했습니다. 여기서 한 가지 구분해서 볼 부분은 이벤트 스토밍에서 나온 결과가 곧바로 최종 도메인 모델이 되는 것은 아니라는 점입니다. 이벤트 스토밍을 통해 이벤트, 커맨드, 정책, 주요 도메인 개념을 발견하고, 이후 모델링 과정에서 Aggregate의 책임과 불변식(Invariant)을 정의하면서 새로운 도메인 개념이 발견될 수도 있습니다. 다만 이때 새롭게 발견된 RentalCard 라는 용어 역시 개발자만 사용하는 기술적인 이름으로 끝나서는 안 되고, 도메인 전문가와 논의하여 실제 비즈니스에서도 의미가 통하는 용어인지 확인하는 과정이 필요합니다. 따라서 실제 프로젝트였다면, RentalCard가 우리 업무에서 무엇을 의미하는가? 실제 업무에서는 이 개념을 무엇이라고 부르는가? RentalStatus, RentalAccount, BorrowingRecord 같은 다른 표현이 더 적절한가?` 등을 도메인 전문가와 다시 확인했을 것입니다 . 즉, 유비쿼터스 언어는 이벤트 스토밍 시점에 한 번 정하고 끝나는 것이 아니라 모델링 과정에서 계속 발견되고 정제되는 언어 라고 이해하시면 좋을 것 같습니다. 강의에서는 Aggregate 개념을 설명하기 위해 RentalCard 라는 이름을 사용했지만, 실제 프로젝트라면 이 이름 역시 도메인 전문가와 검증하고 필요하면 변경하는 것이 맞습니다. 2. RentalCard가 ReturnItem 목록을 계속 가지고 있으면 데이터가 너무 커지지 않을까요? 이 부분도 맞습니다. 강의에서는 Aggregate와 일관성 경계, 그리고 대여/반납 규칙을 이해하기 쉽도록 RentalCard 가 관련 Item 목록을 가지고 있는 형태로 단순화했습니다. 하지만 실제 시스템에서 사용자의 전체 대여/반납 이력을 Aggregate 내부에 계속 누적시키는 방식은 일반적으로 바람직하지 않습니다. 예를 들어 한 사용자가 10년 동안 수천 건을 대여했다면, 대여 한 건을 처리하기 위해 과거 수천 건의 ReturnItem을 모두 로딩할 필요는 없습니다. DDD에서 중요한 것은 Aggregate가 모든 관련 데이터를 가지고 있어야 한다는 것이 아니라, 비즈니스 불변식을 지키기 위해 필요한 최소한의 상태를 일관성 경계 안에 두는 것 입니다. 예를 들어 대여 가능 여부를 판단하는 규칙이 현재 대여 중인 책이 5권 이하인가? 연체 중인 책이 있는가? 정도라면 Aggregate에는 전체 과거 이력이 아니라 현재 대여 중인 항목 , 현재 대여 권수 , 연체 여부 등 규칙을 판단하는 데 필요한 상태만 유지할 수 있습니다. 반면 과거의 전체 대여/반납 이력은 별도의 Entity나 Repository, 조회 모델(Read Model) 등으로 분리할 수 있습니다. 즉 개념적으로는 다음과 같이 나눌 수 있습니다. RentalCard → 현재 대여 상태와 대여 가능 여부 등 비즈니스 규칙 관리 Rental / RentalHistory → 개별 대여 및 반납 이력 관리 Read Model → 사용자의 전체 대여 이력 조회 특히 CQRS를 적용한다면 명령을 처리하는 Aggregate와 대여 이력을 조회하는 모델을 명확하게 분리할 수도 있습니다. 따라서 강의의 모델은 DDD의 Aggregate 개념을 설명하기 위해 단순화한 예이고, 실제 현업에서는 Aggregate의 크기가 계속 증가하지 않도록 Aggregate가 보호해야 할 불변식에 필요한 최소 상태만 유지하도록 설계하는 것이 중요합니다. 오히려 질문해 주신 두 가지가 DDD에서 중요한 포인트입니다. 이벤트 스토밍 → 모델링 → 구현으로 진행하면서 유비쿼터스 언어와 Aggregate의 경계는 계속 검증되고 정제될 수 있으며, 처음 만든 모델을 그대로 구현하는 것이 DDD의 목표는 아닙니다. ** 참고로 불변식이라는 것은 Aggregate가 항상 보장해야 하는 비즈니스 규칙을 의미. 예를 들어 최대 5권 대여라는 규칙이 있다면 RentalCard는 전체 대여 이력이 아니라 현재 대여 권수를 정확히 관리하면 됩니다.