डीडीडी बड़े सिस्टम पर कैसे काम करता है? (Ddd Large Systems Bounded Context Context Mapping)

पहले ग़लत प्रश्न को छोड़ें

पहले दिन केवल एक Book मॉडल था। फिर बिक्री टीम ने कीमत पूछी, शिपिंग टीम ने डिलीवरी विंडो मांगी, और मार्केटिंग अभियान की जानकारी जोड़ी। छह महीने बाद, वही कक्षा एक ऐसी वस्तु में बदल गई जिसे कोई भी पूरी तरह से समझ नहीं पाया। समस्या यह नहीं है कि किताब बढ़ रही है; विभिन्न व्यावसायिक इरादों को एक ही मॉडल में लोड किया गया।

एक बड़े सिस्टम को माइक्रोसर्विसेज में विभाजित करना DDD को लागू नहीं कर रहा है। सबसे पहले, यह समझना आवश्यक है कि व्यवसाय के किन हिस्सों में अलग-अलग भाषाएं, निर्णय और परिवर्तन की लय होती है। अन्यथा, आप मोनोलिथ के बजाय अधिक महंगा वितरित मोनोलिथ का उत्पादन करेंगे।```text Tek model → herkesin ihtiyacını taşımaya çalışır → model gerilimi

Satış bağlamı → fiyat ve müşteri kredisi Kargo bağlamı → teslimat adresi ve paket Katalog bağlamı → başlık, ISBN ve metaveri

## पहले उल्लेख पर अवधारणाएँ```text
📦 Bounded Context
Bir modelin, dilin ve kuralların kendi içinde tutarlı kaldığı açık sınır.

📦 Context Mapping
İki bağlamın veri, güç ve sözleşme ilişkisini bilinçli olarak tanımlama pratiği.

📦 Upstream / Downstream
Veriyi veya sözleşmeyi sağlayan taraf upstream; ona bağımlı tüketen taraf downstream'dir.

📦 Anti-Corruption Layer (ACL)
Dışarıdaki modelin kavramlarını kendi domain'inize sızmadan çeviren katman.
```कॉनवे के नियम की सरल व्याख्या यह है: जैसे संगठन संचार करता है, सॉफ्टवेयर समय के साथ उस संरचना को दर्शाता है। बाउंडेड कॉन्टेक्स्ट एक माइक्रोसर्विस नहीं है; सबसे पहले यह एक मॉड्यूलर मोनोलिथ के भीतर एक अलग भाषा, स्वामित्व और कोड सीमा के रूप में रह सकता है।

## बड़ी तस्वीर```text
                         Şirket
                            │
       ┌────────────────────┼────────────────────┐
       │                    │                    │
    Katalog              Satış                Kargo
       │                    │                    │
     Book               Customer             Recipient
       │                    │                    │
       └──────── OrderConfirmed event ────────┘
                            │
                         Outbox
                            │
                          Broker
                            │
                     Delivery projection
```इस आरेख में भौतिक सेवाओं की संख्या शामिल नहीं है; यह दिखाता है कि भाषा, स्वामित्व और परिवर्तन किस सीमा पर रहते हैं।

## एक सच्चे मॉडल की तलाश क्यों टूट गई?

किसी पुस्तक सूची में, यह शीर्षक, लेखक और आईएसबीएन है; ऋण पर, यह शेल्फ पर भौतिक प्रति है; SKU और कीमत बिक्री पर हैं। उन सभी को एक `Book` वर्ग में संयोजित करना पुन: उपयोग नहीं है, बल्कि विभिन्न इरादों को एक साथ बांधना है। वही तनाव `Customer` के लिए देखा जाता है: बिक्री टीम क्रेडिट और बिलिंग जानकारी मांगती है, जबकि कार्गो केवल पता और डिलीवरी प्राथमिकताएं मांगता है।```text
❌ Unified Customer
creditLimit + invoiceAddress + deliveryWindow + marketingConsent + ...

✓ Sales.Customer
creditLimit + billingProfile

✓ Shipping.Recipient
deliveryAddress + deliveryWindow
```समस्या वस्तुओं की संख्या की नहीं है. यह विभिन्न कारणों से विभिन्न टीमों द्वारा एक ही मॉडल का संशोधन है। प्रभावित संदर्भों की संख्या `k` बढ़ने पर यह परिवर्तन लागत कम से कम O(k) हो जाती है; जब निर्भरता बढ़ती है, तो परीक्षण और समन्वय लागत तेजी से बढ़ती है।

## बंधा हुआ संदर्भ: पहले कार्य की भाषा के साथ सीमा बनाएं

सीमा के लिए तकनीकी परतें या डेटाबेस तालिकाएँ न देखें। इन संकेतों पर नज़र रखें:

1. क्या मीटिंग में एक ही शब्द का अलग-अलग मतलब होता है?
2. क्या `if (shipping)`, `if (sales)` जैसे विशेष मामले किसी मॉडल में गुणा होते हैं?
3. क्या टीमें एक ही बदलाव के लिए लगातार एक-दूसरे का इंतजार कर रही हैं?
4. क्या किसी डोमेन का स्वामित्व, सफलता का माप और परिवर्तन की लय अस्पष्ट है?

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

## मोनोलिथ में प्रारंभ करें; परिणाम के रूप में माइक्रोसर्विस देखें

बाउंडेड कॉन्टेक्स्ट को सत्यापित करने का सबसे कम जोखिम वाला तरीका एक मॉड्यूलर मोनोलिथ है। संदर्भ का अपना अनुप्रयोग/डोमेन/बुनियादी ढांचा घटक, डेटा एक्सेस और स्पष्ट अनुबंध है; लेकिन यह अभी तक वितरित कॉल की परिचालन लागत वहन नहीं करता है।```text
Catalog module ── published contract ──► Sales module
Sales module   ── domain event ─────────► Shipping module

Her module: kendi dilini, use case'lerini ve sahipliğini korur
```माइक्रोसर्विसेज में माइग्रेट करना केवल तभी समझ में आता है जब कोई सिद्ध आवश्यकता हो, जैसे स्वतंत्र स्केलिंग, स्वतंत्र तैनाती, विभिन्न सुरक्षा सीमा, या सच्ची टीम स्वायत्तता। बंधा हुआ संदर्भ = माइक्रोसर्विस समानता शीघ्र तैनाती का सबसे आम कारण है।

## संदर्भ मानचित्रण: एकीकरण एक संयोग नहीं होना चाहिए

संदर्भों के बीच संबंध शक्ति संतुलन और मॉडल संदूषण से निर्धारित होता है, एपीआई समापन बिंदु से नहीं।

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

ACL उदाहरण में, कार्गो संदर्भ लीगेसी ERP के `CUST_TIER=7` फ़ील्ड को अपनी `DeliveryEligibility` अवधारणा में परिवर्तित करता है। ईआरपी शब्द कार्गो डोमेन के अंतर्गत नहीं आता है। यह परत अतिरिक्त कोड की लागत है; बदले में, जब बाहरी प्रणाली बदलती है, तो प्रभाव एक ही अनुवाद बिंदु पर रहता है।

## घटना, आउटबॉक्स और अंतिम स्थिरता

एक संदर्भ को दूसरे संदर्भ का डेटाबेस नहीं पढ़ना चाहिए. जब बिक्री किसी ऑर्डर की पुष्टि करती है, तो वह `OrderConfirmed` ईवेंट जारी कर सकती है; कार्गो इससे अपना स्वयं का डिलीवरी दृश्य उत्पन्न करता है। ईवेंट सिंक्रोनस कॉलिंग पर पूरी तरह से प्रतिबंध नहीं लगाता है; लेकिन स्वतंत्र कार्यप्रवाह में अस्थायी निर्भरता को कम करता है।```text
Sales transaction
  → Order'ı kaydet
  → Outbox'a OrderConfirmed yaz
  → Commit

Relay → Broker → Shipping consumer → Delivery projection
```आउटबॉक्स आवश्यक है क्योंकि ब्रोकर और डेटाबेस समान ACID लेनदेन साझा नहीं करते हैं। यदि कोई ऑर्डर रिकॉर्ड है, तो प्रसारित होने वाला एक कार्यक्रम भी है; रिले पुनः प्रयास कर सकता है. उपभोक्ता को निष्क्रिय होना चाहिए क्योंकि उसे डुप्लिकेट ईवेंट प्राप्त हो सकते हैं। अंतिम स्थिरता कोई त्रुटि नहीं है, बल्कि समय की एक दृश्यमान खिड़की है जिसे उत्पाद को स्वीकार करना होगा।

## इस डिज़ाइन की कीमत

संदर्भ सीमाओं के लिए अधिक समझौतों, अवलोकन, संस्करण और टीम अनुशासन की आवश्यकता होती है। प्रत्येक नया उपभोक्ता केवल O(1) कोड ही नहीं जोड़ता; इसमें डैशबोर्ड, अलार्म, पुनः प्रयास, स्वामित्व और एकीकरण परीक्षण भी जोड़ा गया है। इसलिए, सर्वोत्तम सीमा वह नहीं है जो सबसे अधिक सेवाएँ उत्पन्न करती है; यह वह सीमा है जो वास्तव में परिवर्तन की लागत को कम करती है।

## मिलान जो झूठा आत्मविश्वास पैदा करता है```text
❌ Bounded Context = mikroservis
✓ Bounded Context önce dil, sahiplik ve model sınırıdır.

❌ Tek model = tutarlılık
✓ Her bağlamın kendi tutarlı modeli olabilir.

❌ Shared Kernel = yeniden kullanım
✓ Shared Kernel ortak değişim ve koordinasyon maliyetidir.

❌ REST çağrısı = entegrasyon stratejisi
✓ Sözleşme, sahiplik ve hata davranışı stratejidir.

❌ Eventual consistency = hata
✓ Doğru tasarlanırsa bağımsız iş akışının bilinçli trade-off'udur.

रणनीतिक डिज़ाइन चेकलिस्ट

1. एक ही शब्द के अलग-अलग अर्थ कहाँ से शुरू होते हैं?
2. क्या भाषा के स्वामी, स्वामी और प्रत्येक संदर्भ के सफलता मानदंड स्पष्ट हैं?
3. क्या इस सीमा को पहले मॉड्यूलर मोनोलिथ के भीतर सत्यापित किया जा सकता है?
4. क्या अपस्ट्रीम मॉडल सीधे आपके डोमेन में घुसपैठ करता है; क्या एसीएल आवश्यक है? उदाहरण के लिए, प्रवाह ERP → ACL → Shipping में, CUST_TIER=7 को कार्गो की अवधारणा DeliveryEligibility में अनुवादित किया जाना चाहिए।
5. क्या साझा अनुबंध पिछड़ा संगत और संस्करणित है?
6. यदि ऑर्डर पूरा होने के बाद ब्रोकर क्रैश हो जाए तो क्या होगा? आउटबॉक्स रिकॉर्ड और ईवेंट को उसी स्थानीय लेनदेन में प्रकाशित करने के लिए लिखता है; जब रिले ब्रोकर वापस आता है, तो यह फिर से सुरक्षित रूप से प्रयास करता है।
7. क्या इवेंट में देरी, डुप्लिकेट और रीप्ले के लिए उत्पाद और परिचालन संबंधी निर्णय हैं?

कोड केवल कुछ पंक्तियों से नहीं बढ़ता है; निगरानी, ​​अलार्म, पुनः प्रयास और ऑपरेशन ओवरहेड भी जोड़े गए हैं। यद्यपि कोड वृद्धि O(1) प्रतीत हो सकती है, परिचालन लागत रैखिक रूप से नहीं बढ़ती है। सेवाओं की संख्या नहीं; विनिमेयता और त्रुटि अलगाव को मापें।

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

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

वास्तुशिल्प सीमा वह जगह है जहां कोड रुकने से पहले निर्णय लिया जाता है, किस भाषा में और यह किसकी जिम्मेदारी के तहत है।

अंतिम अनुभाग में, हम डीडीडी के उत्पादन जीवन की जांच करेंगे: इवेंट स्टॉर्मिंग, विरासत परिवर्तन, भ्रष्टाचार-विरोधी परत और परिवर्तन को सुरक्षित रूप से आगे बढ़ाना।