सीआरयूडी (बनाएं, पढ़ें, अपडेट करें, हटाएं) से सीक्यूआरएस (कमांड क्वेरी रिस्पॉन्सिबिलिटी सेग्रीगेशन) तक: समस्या मॉडल है, कोड नहीं (Crud To CQRS Why We Need Separation)

सीआरयूडी वर्षों तक बढ़िया काम क्यों करता है?

सीआरयूडी बुरा नहीं है. यदि आपकी टीम तीन लोगों की है, तो आप एक ही उत्पाद विकसित कर रहे हैं, और आप प्रतिदिन कुछ सौ अनुरोधों को पूरा करते हैं; Controller → Service → Repository → Database स्ट्रीम एक आदर्श समाधान है। यह तेज़ है, यह स्पष्ट है, नए डेवलपर के दिमाग में उतरना आसान है।```text İlk gün

Product ↓ Controller ↓ Service ↓ Repository ↓ Database टूटना उत्पाद की वृद्धि से आता है, कोड की गुणवत्ता से नहीं। शुरुआत में, आप केवल उत्पादों को सूचीबद्ध करते हैं। छह महीने के बाद, मार्केटिंग एक फ़िल्टर मांगती है; बिक्री के लिए रैंकिंग की आवश्यकता होती है; ऑपरेशन अनुरोध निर्यात; प्रबंधन डैशबोर्ड चाहता है. वही `Product` पैटर्न अचानक बीस अलग-अलग उद्देश्यों को पूरा करने लगता है।text Marketing → filtre Sales → sorting Operations→ export Management→ analytics + dashboard

                ↓

          aynı Product modeli

रोजमर्रा की जिंदगी में इसका संकेत आमतौर पर एक निर्दोष समापन बिंदु है:```text
Bugün
GET /products → 10 ms

Altı ay sonra
GET /products
  ↓ Category
  ↓ Reviews
  ↓ Seller
  ↓ Campaign
  ↓ Discount
  ↓ Stock
  ↓ Warehouse
  ↓ Shipment
  ↓ Favorites

aynı endpoint, farklı ekranları beslemek için büyür
```जूनियर के लिए लघु शब्दावली:```text
📦 Aggregate
İş kurallarını bir arada koruyan domain nesnesidir.

📦 Invariant
Her koşulda doğru kalması gereken iş kuralıdır.

📦 Transaction boundary
Ya hep ya hiç birlikte kaydedilmesi gereken işlemlerin sınırıdır.

📦 Projection
Bir olayı, okuma için hazırlanmış yeni bir görünüme dönüştüren işlemdir.

📦 Read model / DTO
Ekranın ihtiyacı kadar alan taşıyan, okumaya uygun veri görünümüdür.
```इस लेख की कहानी इस बिंदु से शुरू होती है: CQRS तकनीक को बदलकर नहीं, बल्कि विभिन्न मॉडलों को अलग-अलग इरादे देकर इस तनाव को कम करता है।

## सीआरयूडी कब अड़चन पैदा करता है?

सीआरयूडी दृष्टिकोण में, पढ़ना और लिखना एक ही प्रतिनिधित्व पर मिलते हैं। लेखन पक्ष नियम, निरंतरता और परिवर्तन बनाए रखना चाहता है। पढ़ने के पक्ष में तेज़ फ़िल्टरिंग, छोटे डीटीओ, खोज, सॉर्टिंग और डिस्प्ले-अनुकूल फ़ील्ड की आवश्यकता होती है। जब एक एकल मॉडल एक ही समय में इन जरूरतों को पूरा करने का प्रयास करता है, तो दो प्रकार की लागतें उत्पन्न होती हैं।

पहली तकनीकी लागत है. एक साधारण सूची स्क्रीन के लिए, समग्र संबंध लोड हो जाते हैं, अनावश्यक जोड़ बन जाते हैं, और डेटा एक्सेस की लागत बढ़ जाती है। दूसरा संज्ञानात्मक लागत है. फ़ील्ड जोड़ने से एक टीम की रिपोर्ट सही हो जाती है जबकि दूसरी टीम का लेन-देन नियम प्रभावित होता है।```text
100 kullanıcı
  → tek API + tek model
  → CRUD yeterli

5.000 kullanıcı
  → liste, filtre, rapor, iş akışı
  → modelin niyetleri çatışmaya başlar

100.000 kullanıcı
  → okuma ve yazma yükü asimetrik
  → tek model değişimin maliyetini artırır
```यह प्रवाह प्रत्येक प्रोजेक्ट में समान संख्या में नहीं होता है। संकेत उपयोगकर्ताओं की संख्या नहीं है; अब यह स्पष्ट नहीं है कि मॉडल क्या जिम्मेदारी निभाता है।

## सीक्यूएस: सीक्यूआरएस की छोटी लेकिन महत्वपूर्ण जड़

बर्ट्रेंड मेयर का कमांड क्वेरी पृथक्करण का सिद्धांत सरल है: **प्रश्न पूछने से उत्तर नहीं बदलना चाहिए।**

- कमांड स्थिति बदलता है; इसमें इरादा होता है और उसे कोई मूल्य वापस करने की आवश्यकता नहीं होती है।
- क्वेरी जानकारी लौटाती है; यह देखने योग्य स्थिति को नहीं बदलता है।

यह विधि-स्तरीय अनुशासन एपीआई डिज़ाइन को अधिक पूर्वानुमानित बनाता है। `ApproveInvoice` एक आदेश है; `GetInvoiceSummary` एक प्रश्न है. `UpdateInvoiceStatus`, हालांकि तकनीकी रूप से संभव है, कार्य के इरादे को छुपाता है।

सीक्यूआरएस इस विचार को वास्तुशिल्प स्तर पर ले जाता है। कमांड मॉडल व्यावसायिक नियमों और अपरिवर्तनीयों को संरक्षित करता है। क्वेरी मॉडल वह दृश्य उत्पन्न करता है जिसे उपयोगकर्ता या सिस्टम देखना चाहता है। वे एक ही टेबल साझा कर सकते हैं; दो डेटाबेस, काफ्का या इवेंट सोर्सिंग अनिवार्य नहीं हैं।

## जहां एकल मॉडल टकराता है

आइये आरक्षण व्यवस्था पर विचार करें. लिखने वाले पक्ष को क्षमता, रद्दीकरण, भुगतान और समय स्लॉट नियमों को बनाए रखना होगा। इसलिए, मजबूत सीमाओं और लेनदेन की आवश्यकता है। दूसरी ओर, प्रबंधन स्क्रीन आज की अधिभोग दर, प्रति स्थान सारांश और आगामी आरक्षण को शीघ्रता से देखना चाहती है।

इन दो इरादों को एक ही इकाई ग्राफ़ के साथ फीड करना आम तौर पर इस अनुभवहीन प्रवाह में बदल जाता है:```text
GET /reservations
  → Reservation aggregate + Customer + Payment + Availability
  → domain kurallarıyla iç içe sorgu
  → yavaş ve kırılgan liste ekranı
```CQRS का उत्तर दो अलग-अलग अनुकूलन लक्ष्य निर्धारित करना है:```text
Command: ReserveRoom
  → kapasiteyi doğrula
  → kuralları uygula
  → transaction içinde kaydet

Query: GetDailyOccupancy
  → sadece tarih, lokasyon ve sayıları oku
  → ekrana uygun DTO döndür
```इस भेद के माध्यम से, लेखन मॉडल सटीकता के लिए विकसित हो सकता है और पढ़ने का मॉडल अन्वेषण और गति के लिए विकसित हो सकता है। इसका मतलब यह नहीं है कि प्रत्येक क्वेरी O(1) होगी। हालाँकि, यह अक्सर संपूर्ण डोमेन ग्राफ़ के बजाय लक्ष्य दृश्य में पंक्तियों और फ़ील्ड की संख्या की लागत का अनुमान लगाता है।

## सीक्यूआरएस के लिए निर्णय संकेत

CQRS को इसलिए नहीं चुना गया क्योंकि यह ट्रेंडी है। निम्नलिखित संकेत तब सार्थक हो जाते हैं जब वे एक ही सीमित संदर्भ में एक साथ प्रकट होते हैं:

1. **कार्य-आधारित इंटरफ़ेस:** उपयोगकर्ता केवल `Create`, `Update` बनाने के अलावा और भी बहुत कुछ करते हैं; पुष्टि करता है, आरक्षण करता है, डिलीवरी शुरू करता है या धनवापसी का अनुरोध करता है। कमांड नामों में व्यावसायिक भाषा अवश्य होनी चाहिए।
2. **असममित भार:** पढ़ने वाला ट्रैफ़िक, लिखने वाले ट्रैफ़िक की तुलना में काफी अधिक है, और क्वेरी आवश्यकता डोमेन मॉडल के आकार से भिन्न है।
3. **व्यावसायिक नियम:** एग्रीगेट कई अपरिवर्तनीयों को बनाए रखता है; साधारण डेटा अपडेट अब व्यावसायिक निर्णय नहीं बताता।
4. **परिवर्तन की स्वतंत्र लय:** यूआई और रिपोर्टिंग आवश्यकताओं में लेखन पक्ष के नियमों की तुलना में तेजी से बदलाव होता है।
5. **खुली सीमा वाला संदर्भ:** उस क्षेत्र की भाषा, स्वामित्व और सफलता मानदंड स्पष्ट हैं जो भेद को लागू करेगा।

ये कोई चेकलिस्ट नहीं हैं, बल्कि निर्णय के साक्ष्य हैं। सबसे मजबूत संकेत आमतौर पर यह होता है: यदि टीम एक ही इकाई पर व्यवहार और उपस्थिति दोनों को बदलने के लिए लगातार बातचीत कर रही है, तो मॉडल दो अलग-अलग काम कर रहा है।

## CQRS क्या नहीं है?

पाँच बेमेल हैं जो CQRS को अनावश्यक रूप से महंगा बनाते हैं।

- CQRS संपूर्ण सिस्टम को फिर से लिखने के बारे में नहीं है। यह केवल जटिल बंधे हुए संदर्भ में ही शुरू हो सकता है।
- CQRS दो भौतिक डेटाबेस नहीं हैं. सबसे पहले, कोड में तार्किक अंतर किया जा सकता है।
- सीक्यूआरएस इवेंट सोर्सिंग नहीं है। उनका उपयोग एक साथ किया जा सकता है लेकिन वे एक-दूसरे के लिए आवश्यक शर्तें नहीं हैं।
- सीक्यूआरएस एक संदेश ब्रोकर आवश्यकता नहीं है। शुरुआत के लिए इन-प्रोसेस हैंडलर पर्याप्त हो सकते हैं।- CQRS हर स्क्रीन को माइक्रोसर्विस में बदलने के बारे में नहीं है।

विशेष रूप से सरल व्यवस्थापक पैनल, उथले व्यावसायिक नियम और कम परिवर्तन दर में, क्लासिक सीआरयूडी एक बेहतर विकल्प है। कम भागों का मतलब है कम संचालन, आसान ऑनबोर्डिंग। वास्तुशिल्प परिपक्वता इस बारे में नहीं है कि आप कितनी जल्दी सीक्यूआरएस जोड़ते हैं; इसे इस बात से मापा जाता है कि आप कैसे जानते हैं कि कब नहीं जोड़ना है।

## व्यापार-बंद: आप क्या प्राप्त करते हैं, आप क्या भुगतान करते हैं?

| कमाई | कीमत |
| --- | --- |
| व्यावसायिक इरादे से आदेश | अधिक मॉडल और अनुबंध |
| उपयोग परिदृश्यों के लिए उपयुक्त तेज़ क्वेरीज़ | डुप्लिकेट डेटा का प्रबंधन |
| पढ़ने और लिखने का स्वतंत्र विकास | निरीक्षण हेतु अतिरिक्त प्रवाह |
| असममित भार में स्केलिंग विकल्प | भौतिक भेद में परम एकरूपता |

इसलिए, CQRS निर्णय एक रूपरेखा विकल्प नहीं है, बल्कि एक लागत फ़ंक्शन है: आपके द्वारा जोड़ी गई संरचनात्मक जटिलता आपके द्वारा हटाए गए डोमेन और परिचालन जटिलता से कम होनी चाहिए।

## आरंभ करने का सुरक्षित तरीका

सबसे सुरक्षित मार्ग तार्किक अलगाव से शुरू होता है, शारीरिक अलगाव से नहीं। व्यावसायिक भाषा के आधार पर कमांड और क्वेरी नाम अलग करें। क्वेरीज़ को प्रदर्शन-उपयुक्त डीटीओ में डाउनलोड करें। कमांड पक्ष पर सत्यापन, प्राधिकार और अपरिवर्तनीय सीमाएँ स्पष्ट करें। माप लें. हालाँकि, जब कोई सिद्ध पठन बाधा हो या स्वतंत्र पैमाने की आवश्यकता हो, तो पठन मॉडल को एक अलग भंडार में ले जाएँ।

यह दृष्टिकोण एक अपरिवर्तनीय वास्तुशिल्प छलांग के बजाय एक सीखने की प्रणाली स्थापित करता है।

हम अगले भाग में इस अंतर का पता लगाएंगे: कमांड और क्वेरी पाइपलाइन, मध्यस्थ व्यवहार, लेनदेन सीमा और आउटबॉक्स चयन एक साथ कैसे काम करते हैं?

## सबसे अधिक भ्रमित करने वाली अवधारणाएँ```text
❌ CQRS = Event Sourcing
❌ CQRS = Microservice
❌ CQRS = Kafka
❌ CQRS = Event-driven architecture

✓ Bunlar birbirinden bağımsız yaklaşımlardır.
✓ Birlikte kullanılabilirler; birbirlerinin şartı değildir.
```पहले जिम्मेदारी के पृथक्करण के रूप में CQRS पर विचार करें। एक अलग डेटाबेस, ब्रोकर, या ईवेंट स्ट्रीम केवल तभी जोड़ा जाना चाहिए जब यह एक मापी गई आवश्यकता को पूरा करता हो।

## निर्णय मैट्रिक्स

| आकार | सीआरयूडी | सीक्यूआरएस |
| --- | --- | --- |
| कोड स्टार्टअप सरलता | उच्च | मध्यम |
| रखरखाव में आसानी, सरल डोमेन | उच्च | मध्यम |
| असममित पढ़ने का पैमाना | सीमित | मजबूत |
| सघन डोमेन नियम | यह समय के साथ कठिन होता जाता है | अधिक दृश्यमान सीमाएँ |
| परिचालन लागत | निम्न | तार्किक भेदभाव पर मध्यम, शारीरिक भेदभाव पर उच्च |

यह कोई स्कोरकार्ड नहीं है; यह एक निर्णय उपकरण है जो संदर्भ को दृश्यमान बनाता है। एक साधारण डोमेन के लिए, सीआरयूडी की उच्च सादगी एक वास्तविक लाभ है।

> **सीआरयूडी छोटी प्रणालियों के लिए कोई समस्या नहीं है। समस्या यह है कि एक ही मॉडल विभिन्न इरादों को एक साथ प्रस्तुत करने का प्रयास करता है। CQRS इस समस्या का समाधान तकनीक बदलकर नहीं, बल्कि ज़िम्मेदारियाँ अलग करके करता है।**