डीडीडी- व्यवसाय के लिए सॉफ्टवेयर डिजाइन करना, डेटाबेस के लिए नहीं (Ddd Designing Software Around The Business)

One domain, growing decisions

Keep one e-commerce ordering system in mind throughout this chapter. In year one, Order is a simple record carrying selected products and a total. CRUD is sufficient.

Year 1 → create, list, update orders
Year 2 → promotions and discounts
Year 3 → returns and partial payments
Year 4 → instalments, inventory reservation, shipment
Year 5 → fraud control and country-specific tax

Each need adds more than a field to Order; it adds a decision. A domain is not a software problem. It is the business problem being solved. Here it is the work of safely accepting, pricing, paying for, returning, and delivering an order.

समस्या पहली: कोड व्यवसाय की भाषा क्यों खो देता है?

किसी उत्पाद के शुरुआती दिनों में, यह अक्सर सरल होता है: तालिका बनाएं, समापन बिंदु लिखें, रिकॉर्ड जोड़ें। यह दृष्टिकोण गलत नहीं है. हालाँकि, जब मूल्य निर्धारण, रिटर्न, जोखिम, वितरण और प्राधिकरण नियम बढ़ते हैं, तो सिस्टम का मूल्य तालिकाओं में नहीं होता है; यह इन निर्णयों के सही कार्यान्वयन पर निर्भर करता है।```text Veritabanı → Table → CRUD → Service katmanı → dağınık iş kuralları

İş dünyası → Ortak dil → Domain modeli → Kod → görünür kararlar

## पहले उल्लेख पर अवधारणाएँ```text
📦 Domain
Sistemin çözmeye çalıştığı iş alanı: örneğin sipariş, kredi veya sigorta.

📦 Domain modeli
İşin kurallarını, kavramlarını ve geçişlerini kodda temsil eden model.

📦 Ubiquitous Language / Ortak Dil
İş uzmanı, ürün ve yazılım ekibinin aynı kavram için aynı adı kullanması.

📦 Core Domain
Ürünü gerçekten farklılaştıran ve en yüksek karar karmaşıklığını taşıyan iş alanı.
````PlaceOrder` एक तकनीकी कॉल से कहीं अधिक है: यह ऑर्डर देने का इरादा बताता है। सफल होने पर, `OrderPlaced` एक व्यावसायिक तथ्य बन जाता है। यदि नाम व्यवसाय की भाषा को व्यक्त नहीं करते हैं, तो टीम प्रत्येक नई सुविधा के साथ पुनः अनुवाद करती है।

## Why does the same order break across layers?

When product says “Preferred Customer” while engineering sees only `Status = 1`, one concept has been split into two languages. Which meaning will the next promotion rule follow? Ubiquitous language reduces that ambiguity before implementation begins.

Likewise, `order.Status = Paid` is not a safe behaviour on its own:

```text
order.Status = Paid
  ↓
Was payment actually verified?       → unknown
Was inventory reserved?              → unknown
Could the order already be cancelled?→ unknown

order.ConfirmPayment(payment)
  ↓
verifies payment evidence
applies required business rules
rejects invalid transitions

The point is not to ban setters. It is to give a business rule one owner. Team size changes the economics too: in a short-lived application built by one or two people, CRUD simplicity wins; in a product evolved for years by more than ten people, shared language and explicit ownership pay back faster.

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

यदि टीम छोटी है, उत्पाद एकल है, और नियम कम हैं, Controller → Service → Repository → Database प्रवाह तेज़ और सीधा है। सरल पंजीकरण स्क्रीन, व्यवस्थापक पैनल और अल्पकालिक प्रोटोटाइप के लिए, यह सरलता एक वास्तविक लाभ है। DDD CRUD के विरुद्ध कोई विचारधारा नहीं है।

जब एक ही तालिका में अधिक रिकॉर्ड जोड़े जाते हैं तो ब्रेक नहीं होता है; यह तब शुरू होता है जब एक ही मॉडल को अलग-अलग व्यावसायिक इरादों का प्रतिनिधित्व करना होता है। एक Order का उपयोग एक साथ प्रमोशन, कर, छूट, रिटर्न, स्टॉक आरक्षण, डिलीवरी और जोखिम नियंत्रण के लिए किया जाता है।```text Database-first OrderRow → status = 2 → UpdateOrderStatus()

Business-first Order → ConfirmPayment() → ReserveInventory() → StartFulfilment()

## सामान्य भाषा: अनुवाद कर समाप्त करें

यदि व्यवसाय विशेषज्ञ "पसंदीदा ग्राहक" कहता है और कोड कहता है `UserStatus = 1`, तो सिस्टम में दो अलग-अलग वास्तविकताएं हैं। यह अंतर नए टीम के सदस्य को गलत समझने का कारण बनता है, नियम विभिन्न सेवाओं में दोहराया जाता है, और बैठकें निरंतर स्पष्टीकरण सत्र में बदल जाती हैं।```text
❌ InsertNewSchoolYear()
✓ OpenNewSchoolYear()

❌ UserStatus = 1
✓ customer.MarkAsPreferred()

❌ OrderRow
✓ LoanApplication / Order / Subscription
```आम भाषा हर तकनीकी नाम को व्यावसायिक शब्द से बदलने के बारे में नहीं है। उस संदर्भ में निर्णयों की व्याख्या करने के लिए मॉडल पर्याप्त सटीक होना चाहिए। जिस प्रकार नक्शा पूरी दुनिया को नहीं, बल्कि यात्रा के लिए आवश्यक वास्तविकता को दिखाता है; डोमेन मॉडल प्रासंगिक व्यावसायिक निर्णय का प्रतिनिधित्व करता है, प्रत्येक डेटा का नहीं।

## एनीमिक मॉडल: डेटा को एक वस्तु और व्यवहार को एक प्रक्रिया बनाना

रक्तहीन डोमेन मॉडल एक संरचना है जिसमें सेवा वर्ग सार्वजनिक सेटर्स से भरी संस्थाओं का प्रबंधन करते हैं। `OrderService`, `PricingService`, `DiscountService` और `ShipmentService` समय के साथ अलग-अलग स्थानों पर समान नियम लागू करने लगते हैं। ऑब्जेक्ट केवल डेटा वहन करता है; व्यवहार बाहर रहता है.```text
❌ order.Status = Paid
❌ order.Total = -10

✓ order.ConfirmPayment(payment)
✓ order.ApplyDiscount(discount)
```समृद्ध मॉडल का उद्देश्य सब कुछ एक इकाई में रखना नहीं है। लेकिन इसका अर्थ है व्यवहार के साथ-साथ व्यवस्था के नियमों का पालन करना, जिन्हें कभी नहीं तोड़ा जाना चाहिए। उदाहरण के लिए, भुगतान सत्यापित होने तक कोई ऑर्डर शिप नहीं किया जा सकता। इस नियम का स्वामी केवल एक ही होना चाहिए.

## डीडीडी की लागत और सही संदर्भ

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

| सिग्नल | सीआरयूडी अधिक सुविधाजनक है | डीडीडी निवेश समझ में आता है |
| --- | --- | --- |
| व्यापार नियम | निम्न एवं स्थिर | स्तरित, आलोचनात्मक, सदैव परिवर्तनशील |
| उत्पाद जीवन | लघु प्रोटोटाइप | लंबे समय तक चलने वाला प्रोडक्ट |
| त्रुटि लागत | निम्न | वित्तीय या परिचालन रूप से उच्च |
| टीम वार्ता | एकवचन | एक ही अवधारणा के अलग-अलग अर्थ होते हैं |

जैसे-जैसे नियमों की संख्या बढ़ती है, समाधान की परिचालन लागत अक्सर गैर-रैखिक होती है। जब एक नियम `k` को विभिन्न सेवा में दोहराया जाता है, तो परिवर्तन लागत कम से कम O(k) होती है; यदि नियम एक-दूसरे को प्रभावित करते हैं तो परीक्षण के मामले तेजी से बढ़ते हैं। डीडीडी जादुई रूप से इस लागत को शून्य नहीं बनाता है; यह स्वामित्व और सीमाओं को दृश्यमान बनाता है।

## पहला कदम: भाषा का निरीक्षण करें, कोड को दोबारा न लिखें

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

इस प्रक्रिया में, डेटाबेस, फ्रेमवर्क और एपीआई एडेप्टर हैं; यह डोमेन निर्णय का स्वामी नहीं है.

## मिलान जो झूठा आत्मविश्वास पैदा करता है```text
❌ DDD = katmanlı mimari
✓ DDD = karmaşık iş alanını modelleme disiplini

❌ DDD = çok fazla interface
✓ DDD = kararların ve kuralların doğru sahibini bulmak

❌ Her projede DDD gerekir
✓ Yatırım, karmaşık ve değişen domain'de geri döner

❌ Aggregate = entity grubu
✓ Aggregate = tutarlılığın korunacağı transaction sınırı

❌ Repository = her tablo için vardır
✓ Repository, domain'de anlamlı aggregate root'lar içindir

निर्णय चेकलिस्ट

• सबसे महंगी व्यावसायिक त्रुटि होने पर किस नियम का उल्लंघन किया जाता है?
• क्या व्यवसाय विशेषज्ञ और कोड एक ही अवधारणा को एक ही शब्द से संदर्भित करते हैं?
• क्या status = 2 स्थिति परिवर्तन या सार्थक व्यावसायिक व्यवहार है?
• क्या नियम का कोई एकल स्वामी है; या क्या इसे विभिन्न सेवाओं में दोहराया जाता है?
• क्या यह डोमेन इतना जटिल है कि विश्लेषण लागत लंबे समय में भुगतान कर देती है?

यदि इन प्रश्नों का कोई स्पष्ट उत्तर नहीं है, तो पहले इकाई या ढाँचा न चुनें। पहले समस्या, भाषा और सीमा स्पष्ट करें.

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

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

सॉफ़्टवेयर का महत्व डेटा संग्रहीत करने में नहीं है; नौकरी के सही निर्णयों को लम्बे समय तक कायम रखने की क्षमता।

अगले भाग में हम इस मानसिकता को कोड स्तर तक ले जाएंगे: मूल्य वस्तु, इकाई और समग्र सीमाएँ।

Before moving to tactical patterns

Where do these business decisions live in code? Tactical DDD patterns such as Value Objects, Entities, and Aggregates answer that question. They are not the starting point, however; they are tools for protecting the language, rules, and boundaries made clear here.