AI DDD 툴 : https://app.qlerify.com/
장바구니 기능을 만들고 싶은 단순하게 장바기느를 구매만 이용하는게 아닌 장바구니의 이벤트를 활용(담기/빼기..), 이벤트를 추적해 구매자의 최종 구매 심리적 요인과 구매예측을 만들고 싶음 기본 이벤트를 설계해.... |
이 툴을 사용하기전 DDD에서 소개하는 개념을 간단하게 살펴보겠습니다.
CQRS는 명령(Command) 과 조회(Query) 를 명확히 책임 분리(Responsibility Segregation) 하여 시스템을 설계하는 아키텍처 패턴입니다.
읽기와 쓰기 모델이 분리되어 각각 독립적으로 최적화될 수 있습니다.
| 개념 | 설명 | DDD 요소와 연결 |
|---|---|---|
| Command | 데이터를 변경하는 요청 (예: 주문 생성) | Command, Aggregate Root, When |
| Command Handler | 명령을 받아 도메인 로직 실행 (비즈니스 규칙 검증 포함) | 도메인 서비스 or 애그리거트 메서드 |
| Aggregate Root | 실제 비즈니스 로직이 작동하는 단위. 상태 변경을 캡슐화 | Aggregate Root |
| Event | Command 처리 후 발생하는 결과 (이벤트 소싱일 경우 저장됨) | Then, 이벤트 핸들러 |
| Query | 데이터를 조회하는 요청 (상태 변경 없음) | Read Model, Projection, DTO |
| Read Model | 조회에 최적화된 모델 (DB View, Cache, Elastic 등) | Read Model, Given |
정의: 시스템에 "무언가를 하라"고 요청하는 객체.
예시: CreateOrderCommand, ChangeUserEmailCommand
특징:
상태를 변경하는 의도(Intent) 를 나타냄
보통 쓰기 작업(write) 에 해당하며, 반환값은 없거나 간단한 결과 (ex: 성공/실패, ID 등)
컨트롤러나 API에서 입력값을 받아 생성됨
DDD 문맥에서 역할:
Aggregate에게 전달되어 비즈니스 규칙에 따라 실행됨
CQRS 구조에서는 Query와 명확히 분리됨
정의: 관련된 도메인 객체들의 일관성을 책임지는 루트 엔티티
예시: Order는 OrderItem들을 포함하지만, 외부에서는 Order를 통해서만 접근
역할:
모든 상태 변경은 Aggregate Root를 통해 수행
도메인 규칙과 트랜잭션 경계를 보장
ID로 식별됨
실제 코드 예시 (Kotlin):
class Order(private val id: UUID, private val items: List<OrderItem>) { fun addItem(item: OrderItem) { /* 비즈니스 규칙 검증 후 추가 */ } } |
정의: 조회를 빠르게 하기 위해 최적화된 별도의 데이터 구조
특징:
Command 모델과 분리됨 (특히 CQRS에서 중요)
보통 DB View, Projection, DTO 등으로 구성
일관성보다는 응답 속도를 중시함
예시: OrderSummaryView, UserDashboardDto
정의: 도메인 동작을 검증하기 위한 테스트 시나리오 패턴
→ BDD(Behavior-Driven Development) 스타일의 도메인 테스트에 사용
형식:
Given: 초기 상태(이전 이벤트 또는 존재하는 Aggregate 상태)
When: 명령(command)을 실행할 때
Then: 예상되는 결과(이벤트 또는 상태 변화)
예시 (Kotlin 테스트 코드 형태):
Given(주문이 생성되어 있고) When(상품을 추가하면) Then(상품이 주문에 포함되어야 한다) |
given(OrderCreatedEvent) when(AddItemCommand) then(shouldEmit(ItemAddedEvent)) |
