llm-wiki/raw/company-tech-blogs/domain-event-sourcing-vs-cqrs-greg-young.md

---
title: Greg Young — CQRS Documents (2010) + Event sourcing/CQRS 구분
source_type: company-tech-blog
url: https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf
archive_url: https://cqrs.wordpress.com/wp-content/uploads/2010/11/cqrs_documents.pdf
status: needs-confirmation
confidence: medium
tags: [domain, cqrs, event-sourcing, greg-young, ca-skeleton, company-case-study]
related_branches: [feature-domain-modeling-guardrails]
related_projects: [ca-skeleton-operational-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Greg Young — CQRS Documents (2010) + Event sourcing 구분

> Layer: `raw/company-tech-blogs/` — Greg Young 의 2010 PDF "CQRS Documents". CQRS 용어 원작자의 정의. ca-tmpl 의 "domain event = transport-free fact" 결정의 정의 출처.
>
> **출처 신뢰도 경고**: 개인 PDF 이므로 company-tech-blog 등급으로 취급 (official-doc 아님). CQRS 의 원작자라는 점에서 정의의 권위는 있으나 공식 표준 아님. 보조로 Martin Fowler bliki 발췌 병기.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-domain-modeling-guardrails]] | "ca-tmpl 은 event sourcing 시스템이 아니다 — domain event 는 transport-free fact" 정의의 원작자 출처. CQRS 와 event sourcing 의 분리 근거. |

특정 branch 없이 foundational 조사로 수집한 경우:

- [[raw/project-notes/ca-skeleton-operational-contract]] — Contract #19 (Domain Application Readiness Contract) 의 "domain event 정의" 표준 출처

## 컨텍스트 / 왜 저장했는지

ca-tmpl 결정: "domain event = transport-free fact". Event sourcing/CQRS 와 단순 domain event 의 차이를 명확히 해야 외부 산출물에서 ca-tmpl 을 "event sourcing 시스템" 으로 오해받지 않음. Greg Young 은 CQRS 용어의 원작자.

## 출처 / Source

- 원본 URL: https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf
- 아카이브 URL (redirect 후): https://cqrs.wordpress.com/wp-content/uploads/2010/11/cqrs_documents.pdf
- 저자 / 조직: Greg Young
- 발행일: 2010-11 (PDF), 지속 reference
- 마지막 확인일: 2026-05-27
- **검증 한계**: PDF binary 직접 텍스트 추출 실패 → 본 인용은 사전 정리본 (needs-confirmation). 보조 자료(Martin Fowler bliki) 로 핵심 정의 교차 검증함.
- 보조 자료:
  - Martin Fowler "CQRS" (bliki, WebFetch 검증됨): https://martinfowler.com/bliki/CQRS.html
  - Confluent "Event Sourcing with Apache Kafka" (보조 인용): https://www.confluent.io/blog/event-sourcing-using-apache-kafka/

## 핵심 인용 / Key quotes (verbatim)

### Greg Young CQRS Documents (PDF — 모두 미검증, 사전 정리본)

> **경고**: PDF 본문 텍스트 추출 실패 (binary). 아래 인용은 사전 정리본으로 wording 검증 필요.

> [§CQRS 정의 — 미검증] "CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation)."

> [§CQRS vs Event Sourcing — 미검증] "CQRS is not Event Sourcing. CQRS allows for the creation of a separate read model that can be optimized for queries. Event Sourcing is a way of persisting the state of an aggregate as a sequence of events."

> [§독립 적용 — 미검증] "The two patterns are often used together because they are highly complementary, but each can be applied independently. Many systems benefit from CQRS without event sourcing, and event sourcing can be used without CQRS read models."

> [§Event 정의 — 미검증] "An event is something that has happened in the past. Events are immutable facts; they cannot be undone, only compensated for by new events."

### Martin Fowler "CQRS" (bliki — WebFetch 검증됨, 교차 검증용)

> [Fowler bliki §정의] "CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young."

> [Fowler bliki §원칙] "you can use a different model to update information than the model you use to read information."

> [Fowler bliki §유래] "the conceptual model into separate models for update and display, which it refers to as Command and Query respectively."

> [Fowler bliki §주의] "you should be very cautious about using CQRS...adding CQRS to such a system can add significant complexity."

> [Fowler bliki §Event Sourcing 연결] "these services to easily take advantage of Event Sourcing."

### Confluent "Event Sourcing with Apache Kafka" (보조 — WebFetch 검증됨, event 정의 보조)

> [Confluent §Event 정의] "Each event is a fact, it describes a state change that occurred to the entity (past tense!). As we all know, facts are indisputable and immutable."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| GY-CQRS-C1 | CQRS 는 이전에 하나였던 객체를 두 개로 분리하는 것으로, method 가 command 인지 query 인지에 따라 분리 (Meyer 의 CQS 정의 차용) | [§CQRS 정의 — 미검증] "CQRS is simply the creation of two objects where there was previously only one... (the same definition that is used by Meyer in Command and Query Separation)." | `needs-confirmation` | CQRS 의 원작자 정의 — wording 검증 후 `company-case-study` 승급 가능 | "command/query 분리가 항상 두 객체 분리" 라는 뜻은 아님 — 단일 객체 내 method 분리도 CQS |
| GY-CQRS-C2 | **CQRS 는 Event Sourcing 이 아니다.** CQRS 는 query-optimized read model 의 분리. Event Sourcing 은 aggregate state 를 event sequence 로 영속화하는 방식. | [§CQRS vs Event Sourcing — 미검증] "CQRS is not Event Sourcing. CQRS allows for the creation of a separate read model that can be optimized for queries. Event Sourcing is a way of persisting the state of an aggregate as a sequence of events." | `needs-confirmation` | CQRS 와 event sourcing 의 개념 분리 — Fowler bliki 가 교차 검증 ("first heard described by Greg Young") | "둘 중 하나만 채택" 이라는 뜻은 아님 — 함께 자주 사용됨 (`GY-CQRS-C3`) |
| GY-CQRS-C3 | CQRS 와 Event Sourcing 은 종종 함께 쓰이나(complementary) 독립 적용 가능. 많은 시스템이 event sourcing 없이 CQRS 만으로 이득을 본다. | [§독립 적용 — 미검증] "The two patterns are often used together because they are highly complementary, but each can be applied independently. Many systems benefit from CQRS without event sourcing, and event sourcing can be used without CQRS read models." | `needs-confirmation` | 두 패턴의 독립성 — ca-tmpl 이 둘 다 채택 안 해도 도메인 event 는 정의 가능 | "CQRS 없이 event sourcing 만 채택하는 게 권장" 이라는 뜻은 아님 — 트레이드오프 본 인용 범위 밖 |
| GY-CQRS-C4 | Event 는 과거에 일어난 일. immutable facts. undone 불가, 새 event 로 보상만 가능. | [§Event 정의 — 미검증] "An event is something that has happened in the past. Events are immutable facts; they cannot be undone, only compensated for by new events." | `needs-confirmation` | domain event 의 정의 — Confluent 가 "facts are indisputable and immutable" 로 교차 검증 | event 가 항상 외부 broker 로 발행되어야 한다는 뜻은 아님 (transport-free 가능 — ca-tmpl 채택) |
| GY-CQRS-FOWLER-C1 | CQRS 는 Greg Young 이 처음 기술한 패턴으로, "update 에 쓰는 모델과 read 에 쓰는 모델을 다르게 할 수 있다" 는 원칙 (Fowler 의 정리) | [Fowler bliki §정의/원칙] "CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young." + "you can use a different model to update information than the model you use to read information." | `engineering-blog` | CQRS 정의의 권위 출처 식별 — Greg Young 의 PDF 가 검증 실패해도 Fowler 가 동일 정의 보강 | CQRS 가 모든 시스템에 적합하다는 뜻은 아님 — Fowler 가 "very cautious" 명시 |
| GY-CQRS-FOWLER-C2 | CQRS 도입에는 매우 신중해야 한다 — 부적합 시스템에 추가하면 significant complexity 가 생긴다 (Fowler 의 경고) | [Fowler bliki §주의] "you should be very cautious about using CQRS...adding CQRS to such a system can add significant complexity." | `engineering-blog` | CQRS 채택의 cost 경고 — ca-tmpl 이 CQRS 채택 안 한 결정의 보강 근거 | "CQRS 가 잘못된 패턴" 이라는 뜻은 아님 — 적용 컨텍스트가 중요 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것** (Fowler bliki 한정):
  - `GY-CQRS-FOWLER-C1`: CQRS 의 정의가 Greg Young 에서 유래했다는 사실 + read/write 모델 분리 원칙
  - `GY-CQRS-FOWLER-C2`: CQRS 도입에 "very cautious" 가 필요하다는 Fowler 의 경고 (engineering blog 등급)
- **이 자료가 직접 증명하지 못하는 것** (Greg Young PDF 한정):
  - `GY-CQRS-C1` ~ `C4`: PDF binary 직접 추출 실패로 wording 모두 미검증. Fowler 가 교차 검증한 핵심 (CQRS = Greg Young, read/write 분리) 만 신뢰 가능, 그 외 wording 은 보강 필요.
- **이 자료가 증명하지 않는 것** (일반):
  - "CQRS 는 항상 event sourcing 과 함께 써야 한다" (오히려 `GY-CQRS-C3` 가 반박)
  - event 가 항상 외부 broker 로 발행되어야 한다는 요구 (transport-free fact 가능)
  - ca-tmpl 의 단순 CRUD + domain event 모델이 Greg Young 의 권장 패턴이라는 직접 보증
  - event sourcing 의 운영 비용 구체 (별도 자료 `event-sourcing-vs-outbox-microservices-io` 참조)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - Greg Young PDF wording 의 직접 검증 (pdftotext / 다른 추출 도구 필요)
  - ca-tmpl 의 "transport-free fact" 가 Greg Young 의 event 정의(`GY-CQRS-C4`) 와 정합하는지 도메인 팀 리뷰
  - CQRS 의 "read model 분리" 가 ca-tmpl 의 application port 구분(query/command) 으로 충분한지의 결정 근거

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- ca-tmpl 과의 매핑:
  - **ca-tmpl 채택**: "transport-free fact" = Greg Young 의 "event is something that has happened" 정의와 일치 (`GY-CQRS-C4`). 단 ca-tmpl 은 event sourcing 자체는 채택하지 않음 (state 는 일반 DB row, event 는 부가적 fact).
  - **ca-tmpl 이 채택 안 한 것**:
    - Event sourcing (aggregate state = event sequence): ca-tmpl skeleton scope 밖. outbox-contract branch 가 별도 다룸.
    - CQRS read model 분리: ca-tmpl 은 application port 에서 query/command 구분만 권고. 물리적 분리는 도메인 팀 결정.
- 대안 비교 (도메인 modeling 관점):
  - **rich domain + 일반 CRUD (ca-tmpl 현재)**: 단순, ORM 친화적, event 는 곁다리.
  - **rich domain + event sourcing**: event store 가 SSOT, snapshot 필요, eventual consistency 명시적. 운영 복잡도 高.
  - **functional domain (Scala/F#)**: event = ADT, immutable state transition. JVM Kotlin/Scala 에서 가능하나 ca-tmpl 의 Java/Spring 기본과 충돌.
- 한계:
  - Greg Young 글은 2010년 시점 문서. 이후 event-driven architecture 영역에서 용어가 다양화됨 (event-carried state transfer, integration event 등). ca-tmpl 의 "transport-free fact" 는 가장 좁은 정의에 해당.
- 출처 분류:
  - 본 문서를 official-doc 로 분류하지 않음 (개인 PDF). company-tech-blog 등급으로 취급.

## Related / 관련

- 같은 주제 다른 raw 자료:
  - [[raw/official-docs/event-sourcing-vs-outbox-microservices-io]] (event sourcing — 검증됨)
  - [[raw/company-tech-blogs/outbox-confluent-kafka-connect-smt]] (CDC 기반 outbox)
  - [[raw/company-tech-blogs/outbox-netflix-domain-events-cdc]] (대규모 CDC 사례)
  - [[raw/company-tech-blogs/outbox-wix-engineering-debezium]] (Debezium production — 검증 실패)
- 인용하는 branch:
  - [[raw/branch-notes/feature-domain-modeling-guardrails]]
- 인용하는 wiki: (미작성)

## Followup TODO

- [ ] Greg Young PDF 의 텍스트 추출 (pdftotext / Adobe Acrobat) → wording 검증 후 strength `needs-confirmation` → `company-case-study` 승급
- [ ] Greg Young 의 후속 글 "CQRS, Task Based UIs, Event Sourcing agh!" (goodenoughsoftware.net 403) 의 archive.org 스냅샷 수집