उत्पादन में डीडीडी: वितरित प्रणालियाँ और आधुनिकीकरण रणनीतियाँ (Ddd Production Modernization And Distributed Systems)

The map for this chapter

This chapter is not a list of patterns to memorize. It follows how business truth inside a monolith can move safely while the system changes.

Monolith
   ↓
Event Storming
   ↓
Bounded Context
   ↓
Saga
   ↓
Outbox
   ↓
Strangler Fig
   ↓
Production

उत्पादन में असली सवाल

DDD के साथ सीमाएँ बनाना शुरुआत है। उत्पादन में, वास्तविक परीक्षा सिस्टम और उपयोगकर्ता के विश्वास को बनाए रखना है क्योंकि ये सीमाएँ बदलती हैं। रातों-रात विरासती मोनोलिथ के भीतर ऑर्डर प्रवाह को फिर से लिखना आकर्षक हो सकता है; लेकिन यह आमतौर पर सबसे जोखिम भरा विकल्प है।```text Monolith → mevcut iş gerçeği Yeni bağlam → daha temiz model Kademeli geçiş → ölçülebilir güven

## पहले उल्लेख पर अवधारणाएँ```text
📦 Event Storming
İş olaylarını, komutları ve riskleri birlikte görünür kılan keşif atölyesi.

📦 Saga
Dağıtık bir iş akışındaki yerel işlemleri ve başarısızlıktaki iş telafisini yöneten model.

📦 Transactional Outbox
Veri değişikliği ile yayınlanacak event'i aynı yerel transaction içinde kaydeden desen.

📦 Strangler Fig
Legacy sistemi tek seferde değiştirmek yerine yeni sınırlarla adım adım saran dönüşüm stratejisi.
```एक डोमेन ईवेंट भूतकाल में लिखा गया एक व्यावसायिक तथ्य है: `SiparişOnaylandı`। कमांड का आशय है: `SiparişiOnayla`. यह भेद आवश्यक है; क्योंकि इरादे को खारिज किया जा सकता है, जो तथ्य घटित हुआ वह रिकॉर्ड है जिस पर अन्य संदर्भ विश्वास के साथ प्रतिक्रिया कर सकते हैं।

## इवेंट स्टॉर्मिंग के साथ सबसे पहले अनदेखी स्ट्रीम ढूंढें

उत्पादन परिवर्तन वर्कफ़्लो से शुरू होता है, कोड इन्वेंट्री से नहीं। उत्पाद, संचालन और इंजीनियरिंग एक ही दीवार पर हैं, जो भूत काल में घटनाओं को सूचीबद्ध करते हैं; कमांड, एक्टर्स, बाहरी सिस्टम और रेड हॉट स्पॉट जोड़ता है।```text
SiparişOnaylandı ← SiparişiOnayla ← Customer
       ↓
StokRezerveEdildi ← StokRezerveEt
       ↓
ÖdemeAlındı ← ÖdemeyiAl ← Payment Gateway
```प्रवाह को एक सिरे से दूसरे सिरे तक भी पढ़ें। उलटा आख्यान; यह धन वापसी, आंशिक भुगतान, टाइमआउट और मैन्युअल हस्तक्षेप जैसे सुखद मार्ग से छिपे निर्णयों को दृश्यमान बनाता है। बाउंडेड कॉन्टेक्स्ट एक तालिका का नाम नहीं है; निर्णय वहीं होता है जहां भाषा और स्वामित्व बदल जाता है।

## गाथा: रोलबैक नहीं, काम मुआवजा

जब भुगतान, इन्वेंट्री और डिलीवरी अलग-अलग संदर्भों में रहते हैं तो कोई एकल ACID लेनदेन नहीं होता है। 2पीसी मजबूत स्थिरता का वादा कर सकता है; हालाँकि, समन्वयक या प्रतिभागी की विफलता के मामले में, इसमें लॉक रिटेंशन और एक्सेसिबिलिटी शुल्क लगता है। इसके बजाय सागा प्रत्येक स्थानीय कदम के लिए मुआवजे को परिभाषित करता है।```text
Reserve inventory → Capture payment → Create shipment
                 payment fails → Release inventory
````ReleaseInventory` को भी निष्क्रिय होना चाहिए; यदि एक ही घटना दो बार होती है, तो स्टॉक दो बार नहीं बढ़ना चाहिए। लघु और स्थानीय धाराओं में, कोरियोग्राफी पर्याप्त हो सकती है। बहु-चरणीय, दृश्यता-महत्वपूर्ण प्रक्रियाओं में ऑर्केस्ट्रेशन; एक राज्य मशीन और अवलोकन का एक एकल बिंदु प्रदान करता है।

## आउटबॉक्स और ट्रैसेबिलिटी: माइग्रेशन को सिद्ध करना

यदि किसी ऑर्डर को प्रतिबद्ध करते समय ब्रोकर पहुंच योग्य नहीं है, तो डेटाबेस और संदेश प्रकाशन के बीच एक दोहरी-लेखन अंतर उत्पन्न होता है। इसीलिए आउटबॉक्स मौजूद है।```text
Local transaction
  → Order'ı kaydet
  → OrderConfirmed'i Outbox'a yaz
  → Commit

Relay → Broker → Consumer → Projection
```उपभोक्ताओं को कम से कम एक बार डिलीवरी पर डुप्लिकेट संदेशों की अपेक्षा करनी चाहिए। इवेंट आईडी, समग्र संस्करण और व्यावसायिक प्रभाव की जाँच की जानी चाहिए। सहसंबंध आईडी अंत-से-अंत प्रवाह के भाग को इंगित करता है, और कारण आईडी इंगित करती है कि किस निर्णय ने घटना को जन्म दिया। ये लॉग फ़ील्ड नहीं हैं; "क्या हुआ?" घटना के समय. और "ऐसा क्यों हुआ?" आपके प्रश्नों का उत्तर है.

## स्ट्रैंग्लर चित्र के साथ विरासत रूपांतरण

बिग-बैंग परिवर्तन व्यावसायिक नियमों की खोज से पहले पुराने व्यवहार को खोने का जोखिम है। विरासत के आगे नया संदर्भ आयात करें; पहले डेटा और व्यवहारिक अंतर को मापें, फिर ट्रैफ़िक बढ़ाएं।```text
1. Replication only  → yeni modele veri akıt
2. Shadow reads      → eski ve yeni cevabı karşılaştır
3. Partial reads     → küçük trafik yüzdesini yönlendir
4. Write migration   → yeni sınırda yaz, geri uyumu koru
5. Full cutover      → metriklerle doğrulanmış geçiş
6. Decommission      → köprüleri ve eski kodu kaldır
```एंटी करप्शन लेयर यहां नए मॉडल की ढाल है। विरासत के अस्पष्ट क्षेत्रों को सीधे डोमेन में ले जाने के बजाय, यह अनुवाद करता है: `LEGACY_ORDER_STATE=7` नए संदर्भ में एक सार्थक `FulfilmentStatus` बन जाता है। इस प्रकार, गंदे मॉडल का प्रभाव एक ही एडॉप्टर पर रहता है।

## स्वीकृति मानदंड: रोलबैक क्षमता, न कि केवल तैनाती

माइग्रेशन की सफलता केवल नए समापन बिंदु की प्रतिक्रिया के बारे में नहीं है। छाया पढ़ने में अंतर दर, P95 विलंब अंतर, उपभोक्ता अंतराल, DLQ गहराई और रोलबैक योजना दिखाई देनी चाहिए। घटनाओं की संख्या के आधार पर पुनः चलाने की लागत O(n) है; स्नैपशॉट या खंडित रीप्ले इस लागत को कम कर सकता है, लेकिन सत्यापित इतिहास का विकल्प नहीं है।

जिस प्रणाली का अवलोकन नहीं किया जा सकता उसे प्रबंधित नहीं किया जा सकता। प्रत्येक ईवेंट अनुबंध में एक स्वामी, रिलीज़ रणनीति, अलर्ट और रीप्ले रनबुक होनी चाहिए।

## मिलान जो झूठा आत्मविश्वास पैदा करता है```text
❌ DDD = mikroservis dönüşümü
✓ DDD önce iş dilini ve karar sınırını korur; mikroservis bazen sonuçtur.

❌ Saga = teknik rollback
✓ Saga, geri alınamayan iş etkisini telafi eden iş akışıdır.

❌ Outbox = exactly-once teslimat
✓ Outbox event kaybını önler; consumer yine duplicate için idempotent olmalıdır.

❌ Shadow read = test tamamlandı
✓ Karşılaştırma, canlı trafikte davranış farkını ölçen uzun süreli kanıttır.

❌ ACL = gereksiz katman
✓ ACL, legacy dilinin yeni domain'i kirletmesini engeller.

उत्पादन तैयारी चेकलिस्ट

1. क्या इवेंट स्टॉर्मिंग में हैप्पी पाथ के अलावा हॉट स्पॉट और बाहरी सिस्टम दिखाई दे रहे हैं?
2. क्या प्रत्येक सागा चरण के लिए निष्क्रिय मुआवजे को परिभाषित किया गया है?
3. क्या ब्रोकर की विफलता की स्थिति में आउटबॉक्स डेटाबेस रिकॉर्ड और इवेंट के बीच के अंतर को बंद कर देता है?
4. क्या सहसंबंध आईडी, कारण आईडी, उपभोक्ता अंतराल और डीएलक्यू के लिए अवलोकन है?
5. क्या नया संदर्भ ACL के साथ पुराने मॉडल की सुरक्षा करता है?
6. क्या शैडो रीड, कैस्केडिंग ट्रैफिक और रोलबैक के लिए मापने योग्य सीमाएँ स्थापित की गई हैं?
7. क्या पुराने पुलों की तारीख और मालिक स्पष्ट है?

परिवर्तन की जटिलता को सेवाओं की संख्या से नहीं मापा जाता है। स्वतंत्र परिवर्तन को त्रुटि अलगाव और रिटर्न के प्रमाण द्वारा मापा जाता है।

इस लेख से आपको क्या याद रखना चाहिए

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

आधुनिकीकरण का अर्थ पुरानी व्यवस्था को नष्ट करना नहीं है; व्यवसाय के मूल्य को खोए बिना परिवर्तन की एक सुरक्षित लय स्थापित करना है।