9.0 KiB
9.0 KiB
title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_projects | related_branches | created | last_reviewed | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CQRS — Martin Fowler bliki 원문 | official-doc | https://martinfowler.com/bliki/CQRS.html | raw | medium |
|
|
|
2026-05-27 | 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) 의 선택 기준
- 본 글이 공식 표준 또는 vendor doc 이라는 점 — Fowler bliki 는 personal blog. ThoughtWorks 의 공식 입장이 아님. strength
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- 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:
- 인용하는 project:
- 이 자료를 인용한 wiki 요약: (미작성)