100 lines
9.0 KiB
Markdown
100 lines
9.0 KiB
Markdown
---
|
|
title: CQRS — Martin Fowler bliki 원문
|
|
source_type: official-doc
|
|
url: https://martinfowler.com/bliki/CQRS.html
|
|
archive_url:
|
|
status: raw
|
|
confidence: medium
|
|
tags: [architecture, cqrs, read-model, write-model, ddd, event-sourcing, ca-skeleton-operational-contract]
|
|
related_projects: [ca-skeleton-operational-contract]
|
|
related_branches: [feature-repository-access-permission-contract, feature-domain-modeling-guardrails]
|
|
created: 2026-05-27
|
|
last_reviewed: 2026-05-27
|
|
---
|
|
|
|
# CQRS — Martin Fowler bliki 원문
|
|
|
|
> Layer: `raw/official-docs/` — Martin Fowler 의 bliki "CQRS" (2011-07-14) 원문 발췌. read model 과 write model 의 분리, CQRS 적용 시점/위험에 대한 1차 인용 출처.
|
|
|
|
## Parent / 활용 branch (필수)
|
|
|
|
| Branch | 이 자료가 정당화하는 결정 |
|
|
|---|---|
|
|
| [[raw/branch-notes/feature-repository-access-permission-contract]] | D10 (Repository 가 command path 와 query path 에서 동일 interface 를 강제할지, 또는 query 전용 read model 을 별도 도입할지) 결정의 근거 |
|
|
| [[raw/branch-notes/feature-domain-modeling-guardrails]] | 도메인 모델을 update/display 두 모델로 분리할지 단일 모델로 유지할지의 가드레일 근거 — Fowler 의 "be very cautious about using CQRS" 경고 포함 |
|
|
|
|
## 컨텍스트
|
|
|
|
ca-tmpl 의 Repository 가 단일 인터페이스로 read/write 를 모두 책임지는 단순 모델을 권장할지, 아니면 처음부터 read model 분리를 청사진에 넣을지의 결정. Fowler 의 bliki 가 "CQRS 를 무차별 적용하지 말라" 는 보수적 입장을 명시하므로, ca-tmpl skeleton 의 default 결정 (단일 모델 + 필요 시 분리) 의 1차 근거가 됨.
|
|
|
|
## 출처 / Source
|
|
|
|
- 원본 URL: https://martinfowler.com/bliki/CQRS.html
|
|
- 아카이브 URL:
|
|
- 저자 / 조직: Martin Fowler — bliki (`martinfowler.com/bliki/`), personal blog
|
|
- 발행일: 2011-07-14
|
|
- 마지막 확인일: 2026-05-27
|
|
|
|
## 핵심 인용 / Key quotes (verbatim)
|
|
|
|
> [§Opening] "you can use a different model to update information than the model you use to read information"
|
|
|
|
> [§Main content — CRUD baseline] "The mainstream approach people use for interacting with an information system is to treat it as a CRUD datastore"
|
|
|
|
> [§Main content — separate models] "The change that CQRS introduces is to split that conceptual model into separate models for update and display"
|
|
|
|
> [§When to use it — scaling benefit] "CQRS allows you to separate the load from reads and writes allowing you to scale each independently"
|
|
|
|
> [§When to use it — caution] "you should be very cautious about using CQRS. Many information systems fit well with the notion of an information base"
|
|
|
|
> [§When to use it — complexity] "adding CQRS to such a system can add significant complexity"
|
|
|
|
> [§Architectural patterns — event sourcing combination] "It's common to see CQRS system split into separate services communicating with Event Collaboration"
|
|
|
|
## Claims Extracted / 추출된 주장
|
|
|
|
| Claim ID | Claim | Evidence quote | Strength | Applies to | Does not prove |
|
|
|---|---|---|---|---|---|
|
|
| CQRS-FOWLER-C1 | CQRS 의 기본 정의는 **읽을 때 사용하는 모델과 갱신할 때 사용하는 모델을 다르게** 쓰는 것 | [§Opening] "you can use a different model to update information than the model you use to read information" | `engineering-blog` | read model 과 write model 의 분리를 검토하는 시스템 | 두 모델이 반드시 별도 저장소·별도 서비스여야 한다는 강제는 아님 — 같은 DB 안의 다른 view/projection 도 CQRS 정의에 부합 |
|
|
| CQRS-FOWLER-C2 | mainstream 접근은 정보 시스템을 **CRUD datastore** 처럼 다루는 것 — CQRS 는 이 대안 | [§Main content] "The mainstream approach people use for interacting with an information system is to treat it as a CRUD datastore" | `engineering-blog` | 일반 CRUD 위주 시스템과의 비교 | CRUD 자체가 잘못된 접근이라는 의미는 아님 — Fowler 는 후반에 "many systems fit well with information base" 라고 CRUD 를 변호 |
|
|
| CQRS-FOWLER-C3 | CQRS 가 도입하는 변화의 핵심은 **개념 모델을 update 용과 display 용 두 모델로 분리** | [§Main content] "The change that CQRS introduces is to split that conceptual model into separate models for update and display" | `engineering-blog` | application 의 domain/read model 설계 | 분리가 반드시 데이터 저장 레벨까지 가야 한다는 강제는 아님 (개념 모델 분리만으로도 CQRS 정의 충족) |
|
|
| CQRS-FOWLER-C4 | CQRS 의 잠재 이득 중 하나는 read/write 부하를 분리하여 **각각 독립적으로 scale** 할 수 있다는 점 | [§When to use it] "CQRS allows you to separate the load from reads and writes allowing you to scale each independently" | `engineering-blog` | read-heavy + write-heavy 가 비대칭인 시스템 | 모든 시스템이 이 분리 scaling 으로 이득을 본다는 의미는 아님 — read/write 비율이 비대칭일 때만 의미 |
|
|
| CQRS-FOWLER-C5 | Fowler 는 CQRS 사용에 **매우 신중할 것 (very cautious)** 을 권고 — 많은 정보 시스템은 information base 개념에 잘 맞기 때문 | [§When to use it] "you should be very cautious about using CQRS. Many information systems fit well with the notion of an information base" | `engineering-blog` | CQRS 채택 의사결정 단계 | 모든 시스템에서 CQRS 가 부적합하다는 강제는 아님 — collaborative domain / 비대칭 부하 등 특정 조건에서 적합 |
|
|
| CQRS-FOWLER-C6 | 부적합한 시스템에 CQRS 를 추가하면 **significant complexity** 가 더해질 수 있음 | [§When to use it] "adding CQRS to such a system can add significant complexity" | `engineering-blog` | CRUD 와 잘 맞는 시스템에 CQRS 추가 시 | "significant" 의 정량적 측정은 없음 (코드 라인 수 / 운영 비용 등 구체 수치는 본 인용 밖) |
|
|
| CQRS-FOWLER-C7 | CQRS 시스템은 **Event Collaboration 으로 통신하는 분리된 서비스** 로 split 되는 경우가 흔함 (event sourcing/event-driven 연계) | [§Architectural patterns] "It's common to see CQRS system split into separate services communicating with Event Collaboration" | `engineering-blog` | CQRS + event sourcing + microservices 결합 시나리오 | CQRS 가 반드시 event sourcing 과 결합되어야 한다는 강제는 아님 — "common" 일 뿐, 본 인용으로 의존성 입증은 못 함 |
|
|
|
|
## Usage Boundaries / 적용 경계
|
|
|
|
- **이 자료가 직접 증명하는 것**:
|
|
- `CQRS-FOWLER-C1`~`C3`: CQRS 의 정확한 정의 (read/write 모델 분리) + CRUD 와의 대비
|
|
- `CQRS-FOWLER-C4`: scaling 이득의 메커니즘 (read/write 부하 독립 scaling)
|
|
- `CQRS-FOWLER-C5`~`C6`: Fowler 의 명시적 보수적 권고 ("be very cautious", "significant complexity")
|
|
- `CQRS-FOWLER-C7`: CQRS 와 event collaboration 의 흔한 결합 (common, not mandatory)
|
|
- **이 자료가 증명하지 않는 것**:
|
|
- 본 글이 **공식 표준 또는 vendor doc** 이라는 점 — Fowler bliki 는 personal blog. ThoughtWorks 의 공식 입장이 아님. strength `engineering-blog`.
|
|
- CQRS 가 반드시 event sourcing / 별도 read DB / eventual consistency 를 요구한다는 점 (Fowler 본문은 "common" 이라고만 표현)
|
|
- ca-tmpl 의 default 가 단일 모델이어야 한다는 결정 — Fowler 의 caution 은 일반 가이드이며, 특정 프로젝트의 default 결정과 자동 1:1 매칭되지 않음
|
|
- 구체적인 read model 구현 형태 (materialized view / projection / cache / 별도 service) 의 선택 기준
|
|
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
|
|
- ca-tmpl 의 Repository 가 query / command 분리 인터페이스를 강제할지 ([[raw/branch-notes/feature-repository-access-permission-contract]] D10)
|
|
- 분리 도입 시 read model 의 저장 위치 (동일 RDB view / 별도 search index / cache layer)
|
|
- eventual consistency 가 도입될 경우 사용자 경험·UI 보정 정책
|
|
|
|
## 메모 / Notes
|
|
|
|
- Fowler 의 핵심 메시지는 "CQRS 는 strong tool 이지만, 무차별 사용은 해롭다" — `wiki/concepts/cqrs.md` 작성 시 이 caution 을 본문 상단에 명시할 것.
|
|
- 본 글의 후반부 ("information base", "task-based UI" 등) 는 별도 추가 인용 필요 — 본 raw 는 정의 + scaling + 경고 + event collaboration 4개 축만 보장.
|
|
- DDD 의 Aggregate 와 CQRS 의 관계 (read model 이 aggregate boundary 를 우회하는 패턴) 는 본 글에 직접 없음 — [[raw/branch-notes/feature-domain-modeling-guardrails]] 에서 별도 출처 필요.
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 raw:
|
|
- [[raw/official-docs/microservices-io-transactional-outbox]] (CQRS 와 자주 결합되는 outbox 패턴)
|
|
- [[raw/official-docs/arch-hexagonal-cockburn]] (port 분리와 read/write 분리의 개념적 연결)
|
|
- 이 자료를 인용하는 branch:
|
|
- [[raw/branch-notes/feature-repository-access-permission-contract]]
|
|
- [[raw/branch-notes/feature-domain-modeling-guardrails]]
|
|
- 인용하는 project:
|
|
- [[raw/project-notes/ca-skeleton-operational-contract]]
|
|
- 이 자료를 인용한 wiki 요약: (미작성)
|