llm-wiki/raw/official-docs/cqrs-pattern-azure-architecture-center.md

title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed

title	source_type	url	archive_url	status	confidence	tags	related_branches	related_projects	created	last_reviewed
official-doc / CQRS Pattern — Azure Architecture Center (Microsoft)	official-doc	https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs		raw	high	architecture cqrs read-model write-model materialized-view event-sourcing ca-skeleton	feature-application-query-bypass-contract	ca-skeleton	2026-06-04	2026-06-04

CQRS Pattern — Azure Architecture Center (Microsoft)

Layer: raw/official-docs/ — Microsoft Azure Architecture Center 의 CQRS Pattern 공식 가이드 (2025-02-20 갱신). "single data store CQRS" 와 "separate data stores CQRS" 의 공식 two-tier 분류, 복잡성 경고, 적용 조건을 포함. ca-tmpl 의 CQRS-lite (Alt 2) 와 Full CQRS (Alt 3) 의 결정 근거.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-application-query-bypass-contract	D2 (CQRS-lite — same store 에서 read/write model 분리) 와 D3 (Full CQRS — separate data stores) 의 공식 근거. "simple CRUD" 에는 부적합하다는 Azure 경고가 skeleton default 결정의 보수적 기준을 뒷받침

출처 / Source

• 원본 URL: https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs
• 아카이브 URL:
• 저자 / 조직: Microsoft — Azure Architecture Center (CAF/WAF 팀)
• 발행일: 2025-02-20 (last updated)
• 마지막 확인일: 2026-06-04

왜 저장했는지 / Why archived

Microsoft 의 공식 클라우드 아키텍처 패턴 가이드 (Azure Architecture Center) 가 CQRS 를 single data store 와 separate data stores 두 tier 로 공식 분류한다. 이 두-tier 분류가 ca-tmpl CQRS-lite (Alt 2) vs Full CQRS (Alt 3) 결정의 공식적 프레임. 복잡성 경고 ("this pattern might not be suitable when domain is simple") 는 skeleton default 선택의 근거가 됨.

핵심 인용 / Key quotes (verbatim)

[§Solution — queries definition] "Queries never alter data. Instead, they return data transfer objects (DTOs) that present the required data in a convenient format, without any domain logic."

[§Separate models — single data store] "This approach represents the foundational level of CQRS, where both the read and write models share a single underlying database but maintain distinct logic for their operations."

[§Separate models — single data store, read model] "A read model is designed to serve queries for retrieving data. It focuses on generating DTOs or projections that are optimized for the presentation layer. It enhances query performance and responsiveness by avoiding domain logic."

[§Separate models — different data stores] "A more advanced CQRS implementation uses distinct data stores for the read and write models. Separation of the read and write data stores allows you to scale each model to match the load."

[§Separate models — sync] "When you use separate data stores, you must ensure that both remain synchronized. A common pattern is to have the write model publish events when it updates the database, which the read model uses to refresh its data."

[§Problems — eventual consistency] "When the read databases and write databases are separated, the read data might not show the most recent changes immediately. This delay results in stale data."

[§Problems — complexity] "The core concept of CQRS is straightforward, but it can introduce significant complexity into the application design, specifically when combined with the Event Sourcing pattern."

[§When to use — performance tuning] "Systems where the performance of data reads must be fine-tuned separately from performance of data writes benefit from CQRS. This pattern is especially beneficial when the number of reads is greater than the number of writes."

[§When NOT to use — simple domain] "This pattern might not be suitable when: The domain or the business rules are simple. A simple CRUD-style user interface and data access operations are sufficient."

[§Benefits — independent scaling] "CQRS enables the read models and write models to scale independently. This approach can help minimize lock contention and improve system performance under load."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
AZURE-CQRS-C1	CQRS query 측은 데이터를 변경하지 않으며 domain logic 없이 DTO 를 반환	[§Solution] "Queries never alter data. Instead, they return data transfer objects (DTOs) that present the required data in a convenient format, without any domain logic."	official-vendor-doc	CQRS 에서 query model 의 역할 정의 — ca-tmpl QueryUseCase 반환 타입 설계에 적용	DTO 가 aggregate 를 통해 생성되어야 하는지 직접 projection 이어야 하는지는 본 인용이 명시 안 함
AZURE-CQRS-C2	CQRS 의 "foundational level" 은 single database 를 공유하되 read/write logic 을 분리하는 것 (CQRS-lite)	[§Single data store] "This approach represents the foundational level of CQRS, where both the read and write models share a single underlying database but maintain distinct logic for their operations."	official-vendor-doc	단일 관계형 DB 위에서 read/write model 을 분리하는 패턴 — ca-tmpl Alt 2 의 정의	"foundational" 이 "기본값이어야 한다" 는 권고는 아님 — Microsoft 는 use-case 별 선택을 권고
AZURE-CQRS-C3	read model 은 domain logic 없이 presentation 에 최적화된 DTO/projection 생성에 집중	[§Single data store, read model] "A read model is designed to serve queries for retrieving data. It focuses on generating DTOs or projections that are optimized for the presentation layer. It enhances query performance and responsiveness by avoiding domain logic."	official-vendor-doc	CQRS read model 의 역할과 구현 방향	"presentation layer" 에 최적화된다는 뜻이 web adapter 에 직접 의존해야 한다는 의미는 아님 — hexagonal 에서 port 를 통해 projection DTO 반환 가능
AZURE-CQRS-C4	"more advanced" CQRS 는 read/write 각각 다른 data store 를 사용하며 독립 scaling 이 가능	[§Separate stores] "A more advanced CQRS implementation uses distinct data stores for the read and write models."	official-vendor-doc	separate data store 가 필요한 CQRS (Alt 3)	"more advanced" = "더 나은" 이 아님 — 더 복잡한 패턴이라는 의미
AZURE-CQRS-C5	separate data stores CQRS 는 두 store 간 동기화가 필요하며 write model 이 event 를 publish 해 read model 을 갱신하는 것이 common pattern	[§Separate stores — sync] "A common pattern is to have the write model publish events when it updates the database, which the read model uses to refresh its data."	official-vendor-doc	separate store CQRS 의 동기화 메커니즘	"이 방식이 유일한 동기화 방법" 은 아님 — CDC (Debezium 등) 도 valid 대안
AZURE-CQRS-C6	separate store CQRS 는 eventual consistency 를 유발 — read data 가 최신 변경을 즉시 반영 못할 수 있음	[§Problems] "When the read databases and write databases are separated, the read data might not show the most recent changes immediately. This delay results in stale data."	official-vendor-doc	separate store CQRS 를 채택한 시스템	single store CQRS-lite 는 이 eventual consistency 문제가 없음 — 같은 DB 에서 일관된 read 가능
AZURE-CQRS-C7	CQRS 는 단순 도메인 또는 simple CRUD UI 에는 적합하지 않음	[§When not to use] "This pattern might not be suitable when: The domain or the business rules are simple. A simple CRUD-style user interface and data access operations are sufficient."	official-vendor-doc	CQRS 채택 결정의 "not suitable" 조건 — ca-tmpl skeleton default 로 full CQRS 를 채택하지 않는 근거	"CQRS-lite (single store) 도 불필요하다" 는 뜻은 아님 — 본 인용은 separate store CQRS 와 event sourcing 결합의 복잡성 맥락
AZURE-CQRS-C8	CQRS 는 read > write 인 비대칭 부하 또는 read/write 각각 독립 성능 튜닝이 필요한 시스템에 이득	[§When to use — performance] "Systems where the performance of data reads must be fine-tuned separately from performance of data writes benefit from CQRS. This pattern is especially beneficial when the number of reads is greater than the number of writes."	official-vendor-doc	read/write 부하가 비대칭인 시스템에서 CQRS 채택 조건	"reads > writes" 가 항상 CQRS 를 정당화하지는 않음 — single store projection 으로도 해결 가능한 경우 있음
AZURE-CQRS-C9	CQRS 는 도메인 로직이 복잡하고 event sourcing 과 결합 시 significant complexity 를 유발	[§Problems] "The core concept of CQRS is straightforward, but it can introduce significant complexity into the application design, specifically when combined with the Event Sourcing pattern."	official-vendor-doc	event sourcing + CQRS 결합 시	CQRS 단독 (event sourcing 없이) 의 complexity 는 본 인용에서 별도 언급 없음

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • AZURE-CQRS-C1~C3: CQRS query 측의 "no domain logic + DTO" 원칙 + single store 의 공식 "foundational" 레벨 분류
  • AZURE-CQRS-C4~C6: separate store CQRS 의 정의 + sync mechanism + eventual consistency 문제
  • AZURE-CQRS-C7~C9: CQRS 의 "when not to use" 조건 + 적합 조건 + complexity 경고
• 이 자료가 증명하지 않는 것:
  • Java/Spring Boot 환경에서의 구체 구현 방식
  • ArchUnit 으로 CQRS pattern 을 강제하는 방법
  • hexagonal architecture 와 CQRS 의 통합 패턴 (application port / adapter 배치)
  • "foundational level (single store)" 이 ca-tmpl skeleton 의 default 여야 한다는 결정 — Azure 가 권고한 것이 아니라 본 research 의 inference
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • Alt 2 (CQRS-lite) 에서 read model 이 application layer 의 port 를 통해 반환될 때 hexagonal purity 유지 방법 (web DTO / JPA entity leak 방지)
  • Alt 3 (Full CQRS) 를 escalation 조건으로만 채택할 경우 opt-in 계약의 범위

메모 / Notes

• Azure Well-Architected Framework 의 "Performance Efficiency" pillar 근거로 CQRS 채택을 권고 — 이는 platform-agnostic guidance 이며 Java/Spring 특화 내용 아님
• "foundational level = single store" + "more advanced = separate stores" 두-tier 분류는 ca-tmpl Alt 2 와 Alt 3 의 official framing 으로 직접 활용 가능

Related / 관련

• raw/official-docs/cqrs-fowler-bliki — CQRS 개념 원작자 Martin Fowler 의 caution 경고
• raw/company-tech-blogs/domain-event-sourcing-vs-cqrs-greg-young — CQRS 원작자 Greg Young 의 정의
• raw/branch-notes/feature-application-query-bypass-contract — 본 자료를 소비하는 branch